It is time to say it aloud: most of software development books are dangerous.
And when I say books, I don’t mean the shameless waste of not renewable resources like ASP.NET in 21 days, Visual Studio for Dummies, and other printouts of help pages, screen shots, tutorials, and code sample listings. No, I mean books like Software Design Patterns by GoF, Object Oriented Analysis and Design by Booch, Extreme Programming series by Kent Beck, and other iconic and deeply philosophical books.
Ever since Brooks’ Mythical Man-Months we software engineers believe in existance of Software Development Crysis, shame ourselves for the poor quality of software we produce, and desperately dream about the silver bullet, this magical and beautiful thing that would finally liberate us from our guilt complex.
Now, here is the silver bullet: we are not guilty. Guys, we overestimate our control over software quality.
Time pressure and unrealistic deadlines are the number one reason to cut on software quality. Therefore, we try and go into unbelievable deeps of smart and sophisticated processes and methodologies to squeeze yet another 5% of efficiency and free up yet another hour we can dedicate to the only activity that can increase software quality – to the thinking.
But being completely honest to ourselves, we cannot deny that having 5% more or 50% less thinking time would not play any significant role to the outcome. To achieve really satisfying results, we need much more thinking time. So much time that some people even believe we would work on software endlessly if we were allowed to. Unfortunately, it is often impossible. There is almost always a deadline, either due to budget constraints, or coming from marketing strategy to use the big wave of some launch event, or even to win over a competition and be first on the market.
There is no such thing as enough time in a software development project. But looking at the bigger picture, I can’t help asking myself: is the software development phase of the project really the bottleneck? The part where the whole software quality gets lost? Because of these poor software developers unable to write a bug-free software in the first try, and with the speed of a typist? Are the activities happening before the development phase also so sophisticatedly optimized and mercilessly streamlined like ours?
And the answer is often no.
I speak about cases, where pre-development activites are paused for two weeks just because some important decision maker acts as a bottleneck due to his busy schedule. A whole two weeks lost! We would implement a couple of additional features, or 50 unit tests, if we had this time!
I speak about cases, where an important information making the planned software architecture to explode comes in too late, just because some team members either incompetent or playing politics.
I speak about cases, where software development is being outsourced, and the customer’s Purchase and Legal spend a month to negotiate terms and conditions with the vendor whom this customer has already been worked with for a year.
I speak about cases, where the project setup includes several vendors that must cooperate but are in competition with each other, so each inquiry would take at least a couple of days and involve quite a lot of politics.
I speak about cases, where software development workgroups are not stable teams of people who have already been worked together and know each other strenghts and weaknesses, and be able to trust each other, but rather being dynamically gathered together from people who coincidentially were free at the project kickoff time. So that the workgroup has to spend days for neccessary philosophical discussions and alignment…
And this is why I think the books are dangerous. They imply that selection of a programming language, coding style, diagram graphical language, choosing exact procedures to exchange information inside the workgroup, the release timeline, and all such stuff, is important. Often, it isn’t very important. They imply that if we do everything right, we can achieve reasonable software quality. Often, it’s not true. And they imply that we are those who is most responsible for software quality. Sometimes, we are the least responsible for it.
Before going into the great lengths and discussing how yet another programming language would make the software better, wouldn’t it be more reasonable to profile the whole software project and eliminate the biggest waste first?..