Pages

Friday 21 December 2007

Battling the Passe

My whole day was spent in trying to find the source of a many an issue, each of which, if eliminated would make the product I am working on look more polished. The more critical things having been addressed, these are what I term less critical, but necessary finishing touches.

Yet, when you are working on a product where the components are by and large passe and someone has already done it before, probably better; the only way out in software is sometimes fix the symptom of the problem before you find what really causes it. In most cases tracing aetiology of indeterministic and non-repeatable bugs happens by chance.

I believe that the chief architect of a product must anticipate and understand what is necessary rather than what is best. There must be an incentive for providing in short time the necessary ones before closing in on the best solution which would be an end-point. This requires a vision and imagination of a product long before one has even got to the drawing board. This is the one thing I see lacking in completeness.

Christmas season already having arrived, I would like to think of the pleasant things in life and rather cherish the time than crib about bad architects. One can spend hundreds of hours on a badly designed product and achieve nothing much, save wasting precious time. People justify why they "could not" have achieved better once the design imposes constraints that are hard to work around. Last Christmas a prototype of this product was made ready and had a problem no one anticipated, but the architect decided was good enough. The results were of course discontent remarks. The bridge between expectation and realisation wasn't built right. That would entirely be a PR exercise.

Despite the reasons, I am unhappy at being at the same level one year later. There are so many reasons one can attribute it to. Much could have been solved by stronger investment in testing equipment when there was known uncertainty with Silicon components and problems whose source was too difficult to identify with the limited debugging equipment. No one likes to take a risk that could pay off and get things solved. They'd rather waste time than money, as they have no idea that time in today's world is most of the times more precious than money.

If this product does fail in the market, it would be because of archaic architecture and management that is passe. The use of tools and debugging equipment that is not state of the art has added to the uncertainty. Expectation is a license that is free for all, but not by forcing people to slave longer.

No comments:

Post a Comment

You're welcome to comment. As long as you leave your ideas or opinions, please feel free.