At Simple Thread we have a phrase we love repeating: “complexity will come soon enough, no need to engineer it into the system up front.” Of course it is a bit tongue-in-cheek, but it exemplifies the approach we have to building software… and boy do we love building software! Al and I have both been building software for over 15 years, and while we have a lot of other responsibilities these days, there is nothing we love more than creating something and watching people use it.
In that time, software development has changed quite a bit. We’ve been through extreme programming, aspect oriented programming, the agile revolution, SOAP, software factories (apparently this one is coming back, thanks to CA), RAD, UML, the rise of SOA (and now microservices), Web 2.0, the DevOps revolution, containerization, NoSQL, functional programming, Big Data, the list goes on and on.
Complexity will come soon enough, no need to engineer it into the system up front.
To say our industry is dominated by trends is a gross understatement. Every year a new framework or methodology comes out promising to fix all of our software development woes. “You’ve been doing it wrong all along!” is their rallying cry. And yet, year after year, it seems that the constant march of software complexity continues. The vast majority of this is because we are demanding more and more from our software, but a worrying amount of it can come from the tools and methodologies themselves.
Complexity comes in many forms
Fred Brooks in his seminal 1986 paper “No Silver Bullet – Essence and Accident in Software Engineering” talks about “accidental complexity” (often referred to as “incidental complexity”) and “essential complexity”. Essential complexity is the complexity that arises out of the problems we are trying to solve. It is complexity that can only be reduced by simplifying the problem at hand. Incidental complexity, on the other hand, is the complexity that comes from the tools, frameworks, and approaches we use to write software. In his paper, Brooks argued that we should shift our gaze away from incidental complexity towards essential complexity, because inventions like high level programming languages, time sharing, and “unified programming environments” had reduced the incidental complexity to the point where it was no longer the primary concern.
While I don’t think that anyone would disagree with Brooks’ assertions (especially given the time period), in most systems we come across, there is still a staggering amount of incidental complexity. There are probably a number of factors that play into this, but I think the previously mentioned trend chasing can often be a culprit. Developers will reach for a pattern, tool, or framework simply because they saw Facebook, Microsoft, or some other company was using it and so therefore it makes sense for their system as well. If it is good enough for Facebook, it must be good enough for me!
Your systems mirror your organization and challenges
And therein lies the issue… they are almost certainly solving very different problems than you have. Their concerns around software development are probably very different than yours. Their systems are probably very different than yours. Their amount of resources is different from yours. Their constraints are different. Their scale is different. Now that isn’t to say you shouldn’t use tools and frameworks that other companies produce, on the contrary, we should eagerly seek them out. But we should also just as eagerly evaluate their appropriateness within the context of our organizations, systems, skills, etc…
Unfortunately this way of thinking is all too prevalent, and leads to situations where Brooks’ assertion that incidental complexity is no longer a dominant force seems just plain naive. Seeing a small team of developers struggle with a system that was distributed too early, abstracted too much, or refactored into an unintelligible mess is really sad for us. It means that there are inordinate resources being spent on just maintaining a system that could have been spent on optimizing and reducing its essential complexity. Just think about how much better your system could be, if you didn’t have to spend so much time babysitting it!
Simplicity should be at the top of the list
Brian Kernighan once said “controlling complexity is the essence of computer programming.” There really is no more important a goal to keep in mind than that. I take it as a personal goal, and a professional obligation, to try to reduce the complexity in every system I touch. At Simple Thread, asking “how can I simplify this?” is our rallying cry. We ask it of every system, every business model, every user story, every line of code, every UI/UX decision…every interaction. So next time you find yourself making a decision which will lead to up-front complexity for a hypothetical future payout, just remember: “complexity will come soon enough, no need to engineer it into the system up front.”
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
