The Most Important (and Least Understood) Software Development Fact

Facts and Fallacies of Software Development Book

Facts and Fallacies of Software Development BookI love the holidays – the family, friends, food, drink, and, of course, the gift cards. I love to read and time off plus Amazon Gift Cards means the opportunity to indulge my passion. As the New Year begins, I find myself knee deep in two wonderful books about software development and the workplace. One of these, Facts and Fallacies of Software Engineering by Robert L. Glass, I found fascinating even though it was published over ten years ago. While some of the material is dated, I found that most of the facts and fallacies are as valid today as they would have been decades ago. This alone is disconcerting. You would have expected that, by now, most of these facts and fallacies would be well understood and to some extent corrected. If anything, my experience is that there is less understanding of the true nature of software development now than ever. It should be required reading for anyone in the business of managing software development because it would certainly save many a great deal of frustration by learning vicariously from one of luminaries of software development.

It was just about midway into the 55 facts (Fact 21 in fact), that I stumbled onto what could easily be construed as the most important (and least understood) software development fact in Glass’ book. The fact is titled “Complexity” and states:

For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing t0 do); that’s just the way it is.

Glass, Robert L.; Facts and Fallacies of Software Engineering

Glass goes on to state, “If you remember nothing else from reading this book, remember this.” He closes his statement of fact with “And remember, also, that there are no silver bullets for overcoming this problem. Software solutions are complex because that’s the nature of this particular beast.“

What struck me most about this particular fact and Glass’ treatment of it is how closely it aligns with my experience and things I have written and spoken about in the past. Software development is knowledge work and is generally complex, but a majority of people in software development are unaware of this fact and continue to treat software development as if it were physical (mechanistic) work and either simplistic or merely complicated.

It is by understanding this fact that software development will improve. Why? The things that we employ to combat the Complex are much different than the things that work against the Complicated. The Agile movement was a response against using complicated tactics in the complex world. The Agile philosophy engendered a whole host of frameworks, methodologies and development techniques all of which address the need to address complexity. constructionWhy do large teams not work so well in software development? Why does scrum talk about small teams? Because small teams are better at attacking complexity. Large teams are adequate for attacking the complicated. The same holds true about co-location, dedication, stability, and cross-functionality. These are all things that work well for complexity.

If we want to create better software we would be well to head Glass’ fact. We need to stop treating software development like we are building a house or assembling a car. Software is much too complex to be built using the tired old mechanistic means. Remember that as complexity of the problem increases, the complexity of the solution increases at a much higher rate, along with the risks attendant on increased complexity. If you want to mitigate your risk, it is essential that you learn how to properly deal with complexity. You might want to learn how to become Agile.