Present and the Possible in Software Development

The Present and the Possible There is a gap between what is possible and what is present - what is done - in the software industry. How much time and effort is wasted, how much re-inventing and re-discovery is done because we don't always understand the hard won insights from the past about what is required to create quality, sustainable product? How many companies have not realized the success of process improvements, like Agile, because they have not really understood its principles? This gap, and the pain and waste it causes, is frustrating. Closing the gap involves a little re-orientation, becoming intentional to learn and try and adjust, to improve continually. To become more professional. Professionals strive to build on the learnings of others. They avoid taking unnecessary shortcuts, especially when that could harm the product over the long term (imagine what would happen to the civil engineer who kludges together something for the last 2 feet of a bridge just to get it finished up or just to try some new, cool idea). They follow the best practices in how we develop and manage people, in the processes and methods we use, and in the proper way to use tools and technologies.  Laws of the Wood Professional carpenters know that there are certain "laws of the wood" that they must follow in order to build products that will endure and to build them efficiently and profitably. For example, cross-cutting across the grain give you one kind of cut and cutting with the grain is very different. They are basic laws or principles that must be followed to avoid wasted effort, wasted wood, designs that fail. We have our own "Laws of the Wood." For example, there are design principles such as the Dependency Inversion Principle, the Open-Closed Principle, the Liskov Substitution Principle (all things that we have written about in Design Patterns Explained). Failing to work within these laws, principles, forces, leads to wasted effort, products that cannot be maintained, designs that fail. Bob Martin has been advocating this for a long time, calling software developers to become "craftsmen." While Alan uses the term "professional" to describe this, he is in "violent agreement" with Bob and his intent. It is time for us to raise the bar in terms of how we are building software. But what about creativity? We don't like to be constrained as developers. Far from taking away creativity, cooperating with these laws and principles allows creativity to flourish. It helps reduce the complexity in what is surely one of the most complex of human endeavors so that what we do create has the greatest chance of succeeding. In the 1960's, NASA put a man on the moon. They cooperated with their "laws of the wood" (e.g. gravity) to create solutions to an amazing array of problems to create a thing of beauty. The laws give us parameters and boundaries within which to be innovative and get problems solved. If you don't follow the laws, principles, you just won't be as effective. The Long Journey Why don't people follow the laws of development? They don't understand the implications of not following the laws...  They feel time pressures: feel a need for a short cut now.   They fall back into old habits, Sadly, these short cuts don't always give longer term gain... and if they understood the principles better, the good practices approach is just as efficient as those "short cuts." It is natural. And change is going to involve taking what Gemba Panta Rei and Toyota calls the "long path". What this means is that we adopt a mindset to make progressive improvement, learning as we go and adjusting our thinking as we discover what does or does not work. Constantly, intentionally perfecting what we do, sometimes in small steps that take us down the right path. The good news is that, at some level, many developers do know - or almost know - many of these good practices. They may be buried in our intuition, but at least they are not foreign to us. Sometimes, it is ju