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