The right amount of pesimism
Friday, 23. November 2007, 16:13:31
Profesionally, I have an engineering background. Because of this, I learned two basic things during the college years:
1. In a computation, the expressions that are an order of magnitude less than the others can be neglected
2. You have to compute the magnitude of the error for computations
The first principle helps you do the practical stuff quicker, by ignoring what you know it's not important. The second principle helps you keep disasters from happening.
My background often turns me into the most pessimistic member of a software development team. I don't think that's my fault but that my colleagues are too optimistic. I've wrote before about wishful thinking in IT, and the two are related.
The first principle is called in software "levels of abstraction". This basically means designing an application from different points of view and deliberately ignoring the details that are not related to the current level of abstraction. For example, when designing the network structure for the application, don't think about the types used for the database primary keys. Of course, this is an exagerated example, and usually the boundary is thinner, but that's the point.
The second one applies in software through risk management and error minimization for estimations. Whenever I look at a task, I am always thinking:
a) how could this be implemented?
b) how could this be tested?
c) how could this go wrong?
d) what can be done if it goes wrong?
Those last two questions always make me think twice before comitting for a deadline, even if the estimate seems large enough for everybody else.
There are however methods to avoid those problems, once you understand that the IT industry is a little bit different and that other people had the same problem and found solutions. A methodology for estimating (even a very simple one) helps a lot with error reduction, while continuous risk management allows avoiding the worst case scenarios.
In the end, success is possible in software. Only one thing is needed: Discipline. And that's all in your head...
1. In a computation, the expressions that are an order of magnitude less than the others can be neglected
2. You have to compute the magnitude of the error for computations
The first principle helps you do the practical stuff quicker, by ignoring what you know it's not important. The second principle helps you keep disasters from happening.
My background often turns me into the most pessimistic member of a software development team. I don't think that's my fault but that my colleagues are too optimistic. I've wrote before about wishful thinking in IT, and the two are related.
The first principle is called in software "levels of abstraction". This basically means designing an application from different points of view and deliberately ignoring the details that are not related to the current level of abstraction. For example, when designing the network structure for the application, don't think about the types used for the database primary keys. Of course, this is an exagerated example, and usually the boundary is thinner, but that's the point.
The second one applies in software through risk management and error minimization for estimations. Whenever I look at a task, I am always thinking:
a) how could this be implemented?
b) how could this be tested?
c) how could this go wrong?
d) what can be done if it goes wrong?
Those last two questions always make me think twice before comitting for a deadline, even if the estimate seems large enough for everybody else.
There are however methods to avoid those problems, once you understand that the IT industry is a little bit different and that other people had the same problem and found solutions. A methodology for estimating (even a very simple one) helps a lot with error reduction, while continuous risk management allows avoiding the worst case scenarios.
In the end, success is possible in software. Only one thing is needed: Discipline. And that's all in your head...
WIDGETIZE
How to use Quote function: