Being productive, make sure you're not reinventing the wheel

Imagine that each car manufacturer would have to reinvent the wheel for each new car model? Well, now you imagined, what it takes to start up most of the software projects these days. Of course, some start with the basic wheel design already settled, but then the internal combustion engine gets reinvented for sure. Only a minor fraction of software projects get started, and managed as if they are typical engineering tasks. Most of such projects are either simple database frontends, or web-applications built on top of a certain given framework.

As in many aspects of life, software developers often rely on their so called common sense, rather than on sound facts, and analysis. Relative complexity of the subject of software development only enforces the notion that better start doing things first, and ask questions, leave alone plan things, later. Managers are under pressure from stakeholders, who are eager to see things get done. And top all that, dubious results are reported from the use of formal techniques, such as RUP.

The psychology suggests that people tend to minimize the amount of uncertainty in their lives. And uncertanty is what makes the process of planning a software project quite difficult, but only because it actually requires to cope with a devastating amounts of uncertainty. It seems much more productive to start implementing basic functionality right away, but in fact it is just easier, not more productive. And the easiest of all is to start implementing something familiar, say reinvent the wheel, or write another threading subsystem, or a logging library.

Is that truly not obvious that in the present world most of the systems are not that different from one another? Software design patterns were supposed to mitigate that problem, but they only half-way there. In fact most developers only know the design-patterns that they have used already, then they recognize them, and respect them. That is very much attributed to the general lack of tradition of asking questions in the industry. Better yet, the lack of common designs leads to the lack of specialization. Almost every software developer is constantly pushed back and forth, switching from one task to another, that prevents from getting more experience, but rather promotes shallow knowledge of the basic aspects.

The solution to it might be a better templating of software projects, and, yes, dedication of people to some tasks, that they like the most. Managers should resist a temptation to assign a seemingly idle developer to a task that just not up his alley. In fact more attention should be paid to specialization, and education, including self-education of developers.