I often ask attendees of my classes what makes a good design or what makes a design not good. We can all recognize some aspect of a design or implementation in software as being good or not but it can be difficult to talk about why.
When I ask software developers how they describe what is good and not good in software they oftentimes have a difficult time expressing it. It’s not that they don’t know, it’s just that they’ve never thought about how to put it into words. It is like art. We know what we like but it is oftentimes difficult to describe without an example.
There’s a tremendous amount of value in having a vocabulary that allows us to describe what is good and not good in software. Such a vocabulary exists in many other disciplines from civil engineering to brain surgery.
The fact that software developers don’t have a common set of standards and practices is a reflection on how immature our industry is. Yet software development is responsible for billions of dollars. It literally drives our economy and yet the diversity by which it is done across companies can be huge.
If I was in the construction industry and I toured through hundreds of construction companies like I have toured through hundreds of software development companies, I am sure that I would see essentially the same thing over and over again. I am sure that every construction company has some very basic principles and practices that they follow and that they all follow them pretty consistently. If I asked a group of civil engineers what percentage of buildings they build are actually standing a year after they finish they’d probably laugh at me.
Software development company and IT departments are radically different from each other, in my experience. Yes there are some things that they share in common but the way software problems are approached and the way we implement solutions is far from standardized, nor will it probably ever be, at least not to the degree that civil engineering is, because the issues that we face in software development are far more complex and subtle.
We’re not dealing with the laws of physics, for better or worse. We don’t have the constraints of matter in space but we do have other constraints in software development. Just because it happens in a virtual world doesn’t mean that there aren’t laws that govern it.
In software, the key is to manage complexity in such a way that the software we write has a life that can be expanded and changed. This used to not be a concern in our industry and a great deal of the tradition of software development never had to focus on issues related to maintainability, to a large degree. Today though it’s clear that the software we write has to be maintainable and therefore we have to build it with maintainability in mind and understand what makes software easy to maintain and what makes it difficult to maintain.
The focus of my life over the last three decades has been to help software developers design and build software that is more extendable and costs less to work with.
The 30 principles, practices and patterns I teach in my Developer Essentials classes represent a core set of standards and practices that I believe every software development team member would benefit from adopting. It also represents a different perspective than I see most developers have on what software development is and how we should approach it, which often proves valuable to people who have been exposed to it.
These are concepts and practices that are not generally known by most software developers and not taught in schools or even widely practiced on the job, yet they are the techniques of the most successful software developers use. Many of these ideas are not new. They’ve been around for a while and they’re continuing to propagate. I just assembled some of what I found most useful and offer them on my YouTube channel (https://m.youtube.com/channel/UClNB39bdGrUE9dEOtm8J8ZQ) in my classes. For more information, check out my curriculum at http://tobeagile.com/learning-roadmap/.
