Showing posts with label product. Show all posts
Showing posts with label product. Show all posts
Thursday, 11 April 2013
Thursday, 3 January 2008
Expressive!
Today, a good part of the day was spent in trying out some techniques that my mentor recommended for a technical problem. There were results, not dissimilar from prior ones that I had passed through. Either way, it was seen as a positive development.
Most of the day was spent in meetings. A friend who had provided training to colleagues had come to update me on his availability and schedule for the year. I admire his planning and self-driven nature. The usual weekly meeting (normally scheduled on tuesdays), today was mostly driven by me. There was some apathy towards my boss who chaired it, which I did divert by going pretty expressive on ways we could do better going forward.
The one thing I hate is retrospective thought and doubtful thought. The two most hated lines I have heard are "Why didn't you think of this solution which has solved a major issue prior?" and "Do we really require high-end equipment and tools to improve product quality, can't we just improvise with what we (don't) have?" These statements form the lingo of a colleague of mine whom I have been trying to convince with great effort to avoid retrospect and to employ intuition, lateral thinking and risk in solving tough problems. As he has been least receptive, it has been difficult to convince him in one shot, but with expressive moments including today increasing, I am hoping I shall get to him.
I did get a little overboard with my expressiveness towards the evening swallowing almost 1 hour of my colleagues' time in the evening. This basically was in an attempt to converge attitude, thought and method across our team. I do hope that despite whatever boredom I generated, it would have had some help to the ends I've tried to meet. Today has been one of the most expressive of my days where more time was spent on output than on input.
Most of the day was spent in meetings. A friend who had provided training to colleagues had come to update me on his availability and schedule for the year. I admire his planning and self-driven nature. The usual weekly meeting (normally scheduled on tuesdays), today was mostly driven by me. There was some apathy towards my boss who chaired it, which I did divert by going pretty expressive on ways we could do better going forward.
The one thing I hate is retrospective thought and doubtful thought. The two most hated lines I have heard are "Why didn't you think of this solution which has solved a major issue prior?" and "Do we really require high-end equipment and tools to improve product quality, can't we just improvise with what we (don't) have?" These statements form the lingo of a colleague of mine whom I have been trying to convince with great effort to avoid retrospect and to employ intuition, lateral thinking and risk in solving tough problems. As he has been least receptive, it has been difficult to convince him in one shot, but with expressive moments including today increasing, I am hoping I shall get to him.
I did get a little overboard with my expressiveness towards the evening swallowing almost 1 hour of my colleagues' time in the evening. This basically was in an attempt to converge attitude, thought and method across our team. I do hope that despite whatever boredom I generated, it would have had some help to the ends I've tried to meet. Today has been one of the most expressive of my days where more time was spent on output than on input.
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.
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.
Subscribe to:
Comments (Atom)