Hein (fub) wrote,

  • Mood:

On software development

Software development is like armed combat. There is a target functionality, and you need to cover it completely. The difference between large and smaller project teams is how they equip their troops.

You see, if you have a small target and few people, it is feasible to equip them all with rifles. Using squad-level tactics, you can deploy your troops quickly and reactively. If the target moves (that is, the client changes some of the requirements of the desired functionality), all it takes is a slight adjustment in aim to continue to cover the target. Small project teams are very agile, and are best suited for building small systems.

As targets increase in size, you can do one of two things.
One is to add more rifle-equipped troops. This has a practical upper limit, because of diminishing returns -- at a certain point, your troops start to move into eachother's line of fire, communication gets harder, and things may degenerate into chaos. See also: The Mythical Man-Month.

The second possibility is to change the equipment of your troops. Instead of four rifle-men, you could man a piece of artillery with four people. The number of people stays the same, but the power of the process is much higher -- which means you can cover even larger targets in the same time. In software development, the whole set of project methodology, requirements analysis, better tools and a strict programming methodology is the equivalent of a large-caliber cannon.
However, it has a drawback: the artillery needs careful adjustment to hit the target just right. Customers sometimes balk when they find out there is a lot of 'overhead' associated with their projects: project managers, pre-sales consultants, requirements analists, etc. All these people add to the project, but they don't directly build the solution. But because of their work, the actual developers can operate so much more efficient -- nailing the target at the first try.

But it gets worse. If the client changes the specs mid-way (thus 'moving the target') all of the careful calibration of the cannon might have been useless. If you're aiming at a bunker somewhere, but then suddenly you have to take aim at a tank that comes over a hill somewhere else -- it takes time to re-aim the cannon!
So, a strict and thorough project methodology isn't really suited for small projects. But having a cannon pays off for large projects, because you can nail the project with a single, well-aimed hit.

With me so far? Then, here's the lesson of the past two weeks:

It all goes to hell if you try to do a large project and equip all your engineers with the equivalent of rifles. Then, when you find out it isn't going to work, call in the guys with the artillery at the last minute -- but don't adjust your plan of attack for it (that is, don't fix the specs beforehand). Then react snarky if they balk at doing stuff that could more easily be one by a rifleman. And whatever you do, don't manage the project! It might cramp your style!
Tags: technology, work

  • RPG-themed gift exchange

    One of the websites where I spend a lot of time is RPGGeek, the RPG-focused sister site to BoardGameGeek. (The two sites share the same back-end,…

  • Phone case decoration

    We bought a new phone for klik. She likes cases that open like a book, because they protect the screen from scratches when they’re closed. For…

  • Ikebana workshop

    I like learning new things, and the easiest way to get acquainted with a new field is to join an introductory workshop. So when we saw the…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded