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

  • Animal Crossiversary

    One year ago, when the COVID-19 restrictions had just started, Animal Crossing:New Horizons was released. I had pre-ordered and pre-downloaded it…

  • Things that happened this week

    A power interruption. We had gotten a letter from the company that manages the power lines that they’d be working on the infrastructure on…

  • Goodbye 2020

    Remember when Animal Crossing: New Horizons came out just as we went into the first lockdown, and it turned into a bit of a lifeline for many…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded