| A year back I was visiting one of the “Cutting | | | | previous stage has turned into a plant which is visible |
| edge technologies” conferences. I was talking to | | | | from the top of the management pyramid). The top |
| a person in a stall which was displaying an audio-video | | | | management starts asking “uncomfortable |
| movie clipping on ahighly constrained device which had | | | | questions” instead of getting the status |
| a bare minimum OS and having dual core processors | | | | completion of the project in terms of percentages. |
| and various peripheral to support it. The demo was | | | | Manager starts losing confidence in developers and |
| quite impressive and I was discussing about how they | | | | developers, given all these constraints, start coding day |
| are taking it to the next level. | | | | and night to meet deadlines, and one can imagine the |
| Meanwhile, a person standing next to me was looking | | | | quality of code which gets generated during these |
| at the movie and when it ended, he asked | | | | fancy late hours. |
| “What is the oomph factor in this?” | | | | One of my friends gave an exclusive definition of |
| Clearly, a representative of the large crowd, who was | | | | defect-free code which I think perfectly fits in |
| more interested in feature-set rather then the | | | | today’s scenario: |
| underlying technology. These are today’s | | | | A Defect-free code is one where the vendor charges |
| end-users. | | | | the client only for the code which is delivered, the |
| Almost everyday we see gizmos with new | | | | defects in the code are provided free of cost. |
| technologies around us. Features are doubling and | | | | The project which started as a small 3-month project |
| costs are halving every year. Over and above this | | | | starts looking like it would take another century to finish |
| there are factors like market- window and shelf-life | | | | it. The developers are perennially present in office and |
| which are making life tougher for a developer. | | | | whenever asked about the status, the explanation |
| Everybody is talking of how to make the user | | | | starts “Tools are not working, 3rd party is not |
| experience better. But nobody has dared to look at | | | | delivering, quality is causing too much of overhead. I |
| the backstage as to what it translates to, when a user | | | | have been working 18 hours a day…Ask Anyone |
| says I would like it to be better. | | | | Here” |
| For most of the projects, before even the | | | | Only UpperWallah (God) Can Help (OUCH) |
| requirements get decided, first thing which gets | | | | This is when towards the end of the project when the |
| decided is the Release Date/Launch Date. Everybody | | | | customer deliveries are looming on the heads. The |
| in the management tree starts working backwards | | | | components are put together in a way which would |
| with the date and by the time the dates reach to the | | | | even bring a “hacker” to shame. |
| leaves of this whole management tree (developers), | | | | “Make it work somehow” and |
| half of the schedule is eaten up by the intermittent | | | | “How is it going?” are the only two |
| nodes. | | | | phrases which are uttered by the manager from time |
| On top of that, customers are asking for a | | | | to time. |
| zero-defect code, which I think one of the most valid | | | | Somehow (with god’s grace) the components |
| demands. Even though software, by design, cannot | | | | are put together and the BOMB (Built Once with Many |
| always guarantee a 100% fool-proof execution, still all | | | | Bugs) is ready and delivered to the customer. The |
| the testing/quality measures can reduce defects to an | | | | customer as soon as applies the MATCH (Minimum |
| almost negligible margin. | | | | Acceptance Testing Coverage Hub) to the BOMB all |
| This gives rise to what I call | | | | hell breaks loose. |
| “OOH-AAH-OUCH” theory of | | | | All the SLAs measurements starts, 1000 of matrices |
| Developers. | | | | come out and managers become busy with projecting |
| Developer’s OOH-AAH-OUCH Theory | | | | quality data to divert customer attention from the |
| Over Our Head (OOH) | | | | actual issues |
| When the requirement and the schedule which is | | | | Meanwhile, developers are back to the table reading |
| generally driven top-down instead of bottom-up is | | | | requirements and coding even much more than in |
| provided to the developer that is the time when all the | | | | earlier phases. The customer is provided with |
| “oohs” occur. The requirements are like | | | | “hot fixes” and quality, which is talked |
| the UFOs which start flying all over our heads. They | | | | highly by the manager, is thrown out of the window for |
| are not even 10% clear at the start of the project. As | | | | the umpteenth time. |
| each requirement is dug deeper, either it bloats up in | | | | The cycle goes on until each open bus is either closed |
| terms of effort or it goes into what I call is grey area | | | | or listed as a “feature” which may not be |
| which later requires a lot of grey matter to resolve. | | | | used by the end-user. |
| This is the first ominous sign of all the sleepless nights | | | | Conclusion |
| which will happen in the near future. The developers | | | | Though, it may look from the above factors that all the |
| have a choice to work on this sign and reduce the | | | | issues are with the developers and solutions can be |
| damage, but either the “fear of asking silly | | | | found by easily replacing them. But then, if we actually |
| question” or “ego hurt by saying I do not | | | | do the root cause analysis we would find that most of |
| know this” stops them. | | | | the time it is the whole software cycle which is at fault. |
| This is where the seed of the big problem tree is | | | | I think the basic differentiator of software from |
| sown and hardly anybody notices it. | | | | hardware “Software once made can be easily |
| At the end of the project when we do the “root | | | | changed whereas Hardware cannot” has |
| cause analysis” of this tree, most of the times | | | | become the foremost problem. |
| we find this same seed as the problem. | | | | As the software can be changed at a later stage, the |
| Ask Anyone Here (AAH) | | | | detailing is not done in a stringent manner hence |
| This situation starts in the middle of the project where | | | | creating loopholes and room for potential defects. |
| the “blame game” starts. This is the place | | | | We can definitely lay policies and processes to make |
| where the fist realization happens at the top-level that | | | | things more effective, but the most important aspect |
| things are not going right and there might be a problem | | | | we need to change is the mindset of people to |
| (In other words, the seed which was sown in the | | | | “do it right the first time”. |