Once, there was a boy .... what a boy ... golden boy ...
The "golden-boy" antipattern is one of the most glorified antipatterns , yielding a ton of effort on the management the eliminate this "well-known" bottleneck in the system. Whereas this is indeed true - let's ask the golden one what does he think about it:
Golden : "Wha ? hey - I've done a good job and worked hard - it's not my fault that I ended up being golden - no - please - don't take me away ... i will behave ... no..... please.........
A tragic story indeed. However, this is what usually happens as a part of "natural growth" process of a almost each engineering company. Once the organization starts growing in size, the "search for bottlenecks" begin. Naturally - first one that a I-have-read-couple-of-books-on-software-engineering-and-think-I-have-figured-it-out manager would look for is indeed the lookup for the golden one. As a part of this process - a lot of blood will be shed, and as the bottlenecks get "eliminated" - the notion of "gold" will start to diminish,and smaller and smaller "bottlenecks" will be
found. Finally - in the "regression towards the mean" - style - this process can converge to one of two possible outcomes - either the system will become predictable, controllable and easy to manage or it will gradually collapse under the pressure of pending work and inability of the team to deliver it. Still - regardless of the outcome (which mainly depends on the problem domain the organization is addressing) the general flipside of this process is it's natural bias towards "promotion of the averageness".....
(to be continued)
Wednesday, December 3, 2008
Friday, November 28, 2008
Adressing Complexity......
Hard stuff usually boils down to some sort of "handling complexity" problem - ending up at some of the following categories :
a) Computational complexity
- a computationally hard problem => search for cleaver solution, if not , ideal approximation
c) Scale complexity
- problem on a scale order of magnitude larger than imagined => figureout how to scale, how to cut corners
b) Communication complexity
- it's hard to separate problem into pieces => cannot be either paralelized in computational sense , or - cannot be distributed to number of engineers and obtain speedup => redefine the problem ? redefine notion of communication ?
c) Description complexity
- it's hard to describe a problem - is it the problem itself ? or the paradigm used to represent it ? => search for the optimal paradigm ?
d) Representation complexity
- again -> once described, we need a ideal way to represent the problem and manipulate it => ongoing search for optimal representation
This does not only hold for some large-scale-woo-zam projects. If adressed correctly - we will face these issues even in the most trivial projects. What is needed is identifying the complexities we're facing with, and actually redefining the problem itself in the way that will help us adress the complexities more easily. This would yield a completely different perception of the issue - and , indeed, result in far more quality solution that the one obtained by rope-and-the-stick approach.
Finally - this gives a simple rule of a thumb for evaluating work presented - if you cannot identify any of the complexities in it - then it's definitely not something worth wasting time on (but if you really have to - try to add some of your favorite complexity artificially ;) - will make work more fun :) )
a) Computational complexity
- a computationally hard problem => search for cleaver solution, if not , ideal approximation
c) Scale complexity
- problem on a scale order of magnitude larger than imagined => figureout how to scale, how to cut corners
b) Communication complexity
- it's hard to separate problem into pieces => cannot be either paralelized in computational sense , or - cannot be distributed to number of engineers and obtain speedup => redefine the problem ? redefine notion of communication ?
c) Description complexity
- it's hard to describe a problem - is it the problem itself ? or the paradigm used to represent it ? => search for the optimal paradigm ?
d) Representation complexity
- again -> once described, we need a ideal way to represent the problem and manipulate it => ongoing search for optimal representation
This does not only hold for some large-scale-woo-zam projects. If adressed correctly - we will face these issues even in the most trivial projects. What is needed is identifying the complexities we're facing with, and actually redefining the problem itself in the way that will help us adress the complexities more easily. This would yield a completely different perception of the issue - and , indeed, result in far more quality solution that the one obtained by rope-and-the-stick approach.
Finally - this gives a simple rule of a thumb for evaluating work presented - if you cannot identify any of the complexities in it - then it's definitely not something worth wasting time on (but if you really have to - try to add some of your favorite complexity artificially ;) - will make work more fun :) )
Saturday, August 9, 2008
"To test or not to test" : a startup dillema
Despite being well-established in enterprise software development, usage of the tests in dynamic startup-like environments can still be questionable. Having different angle on the software purpose itself - often characterized by "just write something fast, so that we could demo it, and then throw it away"- sort of request, the engineering management is forced to carefully reconsider the trade-offs of (not) introducing a tests into the development process.
Being essentially a gambling turf, in which companies bet on success or failure, startup world is a place in which the best thing one could do is try to do all he can in order to turn odds in his favor, and then hope for good wind in the sails. Adding tests as a part of the process in such environments, at first, doesn't seem like it would do any good in biasing the dice for us, so it's often totally neglected, especially at the beginning of the process. Also, startup teams usually consists of relatively small number of developers, working on a piece of the code, which by definition, requires a significant multiple of that number to be properly done, and allocating some of these scarce resources to something "useless", could really seem like a luxury one cannot afford.
Additionally, in more open minded environments, there is a significant obstacle to introducing tests in small agile teams, and that is the issue of having to keep the team constantly focused on the goal, rather on the details. Namely, being extremely goal-driven, and horribly time-limited, the only way for getting the project done is by rapidly progressing towards the goal and consciously neglecting issues that keep popping up along the way. Having tests in such environment (particularly unit tests) - one is forced to constantly notice those issues and can over time completely loose the focus, which might lead to project failure.
However, though the tests won't get the product done faster and excessive focus on tests could lead to it's demise, there is another side to the flipping dice, that can result in the product failure even though all the features of it have been done properly and on time. For example, the customer might simply change it mind, the market could change at the exact moment the product is out, etc. That is the moment when the investment in tests will pay off. Namely, having software developed with unit testing in mind, automatically forces software to be designed as "testable", and usually, more general and reusable. Such software could easily adapt to the new situation, that might require partial rewrite of the system - in which case ill-designed system would require full redo, and would often yield retract from any further work, and simply admitting project failure. Well-designed system could, on the other hand, keep fighting, reuse it's stable base and move on, which might be a characteristic crucial to the startup's eventual success.
Therefore, one should try and start with the "middle road", as far as the tests are concerned - that is, get them into the system, and have them shaping the development process, but keep them at the minimum level that won't jeopardize other aspects of it. As the time goes by and project advances, the "test volume" should be dynamically tuned up and down, depending on the progress. Tuning that knob properly along the timeline, could shape a curve that just might be the one separating the successful projects from the failed ones.
Being essentially a gambling turf, in which companies bet on success or failure, startup world is a place in which the best thing one could do is try to do all he can in order to turn odds in his favor, and then hope for good wind in the sails. Adding tests as a part of the process in such environments, at first, doesn't seem like it would do any good in biasing the dice for us, so it's often totally neglected, especially at the beginning of the process. Also, startup teams usually consists of relatively small number of developers, working on a piece of the code, which by definition, requires a significant multiple of that number to be properly done, and allocating some of these scarce resources to something "useless", could really seem like a luxury one cannot afford.
Additionally, in more open minded environments, there is a significant obstacle to introducing tests in small agile teams, and that is the issue of having to keep the team constantly focused on the goal, rather on the details. Namely, being extremely goal-driven, and horribly time-limited, the only way for getting the project done is by rapidly progressing towards the goal and consciously neglecting issues that keep popping up along the way. Having tests in such environment (particularly unit tests) - one is forced to constantly notice those issues and can over time completely loose the focus, which might lead to project failure.
However, though the tests won't get the product done faster and excessive focus on tests could lead to it's demise, there is another side to the flipping dice, that can result in the product failure even though all the features of it have been done properly and on time. For example, the customer might simply change it mind, the market could change at the exact moment the product is out, etc. That is the moment when the investment in tests will pay off. Namely, having software developed with unit testing in mind, automatically forces software to be designed as "testable", and usually, more general and reusable. Such software could easily adapt to the new situation, that might require partial rewrite of the system - in which case ill-designed system would require full redo, and would often yield retract from any further work, and simply admitting project failure. Well-designed system could, on the other hand, keep fighting, reuse it's stable base and move on, which might be a characteristic crucial to the startup's eventual success.
Therefore, one should try and start with the "middle road", as far as the tests are concerned - that is, get them into the system, and have them shaping the development process, but keep them at the minimum level that won't jeopardize other aspects of it. As the time goes by and project advances, the "test volume" should be dynamically tuned up and down, depending on the progress. Tuning that knob properly along the timeline, could shape a curve that just might be the one separating the successful projects from the failed ones.
Thursday, August 7, 2008
On Softwareoids
A subdivision of a project into many single-person teams, can often lead to a weird phenomena that can be characterized best as a "human-based software". This is somewhat weird beast, that is usually spawned by assigning a huge project to a single individual. Necessary ingredients to this is (a) having a developer willing to commit to work for more than standard 8h-timeframe ; (b) having a developer lacking a social life (or willingly neglecting it for the sake of work, which he bizzarely considers more "fun").
Facing such person with huge and responsible task, produces the following reaction to given criterias of a task :
a) "It's huge" => "great, i like challenges, and this job is about fun, right ?"
b) "Responsible" => "no problem, if i don't manage to do it properly i can allways stick around the system at all the time (I don't have a life, remember :) ).... and be there to handle it manually if it mailfunctions
Now, reasoning in b), although seemingly courageous, can get everyone in tremendous trouble, not just because of the "golden boy" situation it generates - once that is in production fast, there is no time for it to be rewritten properly, and the person accepting b) becomes your most valuable asset (more than the software).
The main antipattern here is that from software engineering perspective - this had created a hideous beast - a two-headed monster, we might call a "softwareoid" - a code incapable of existence without its maker.
Once in the wild .... that creature can create horrible things......
and that is what this story is all about .....
(to be continued)
Facing such person with huge and responsible task, produces the following reaction to given criterias of a task :
a) "It's huge" => "great, i like challenges, and this job is about fun, right ?"
b) "Responsible" => "no problem, if i don't manage to do it properly i can allways stick around the system at all the time (I don't have a life, remember :) ).... and be there to handle it manually if it mailfunctions
Now, reasoning in b), although seemingly courageous, can get everyone in tremendous trouble, not just because of the "golden boy" situation it generates - once that is in production fast, there is no time for it to be rewritten properly, and the person accepting b) becomes your most valuable asset (more than the software).
The main antipattern here is that from software engineering perspective - this had created a hideous beast - a two-headed monster, we might call a "softwareoid" - a code incapable of existence without its maker.
Once in the wild .... that creature can create horrible things......
and that is what this story is all about .....
(to be continued)
Subscribe to:
Comments (Atom)