Software that Sucks, Brought to You by Engineers, Architects, and Humans
After I published last week’s article on static typing, I read it through one more time and then clicked on one of the recommended articles at the bottom. It was one of those articles that Software Engineers write for other Software Engineers, I guess to commiserate or perhaps to share war stories and cautionary tales. The article is called “10 Modern Software Over-Engineering Mistakes,” and anyone who has been writing code for a few years has probably run into some version of all the problems that the author, RDX, is talking about. He also provides some additional links at the end of his article, which lead to more Engineers writing/presenting to other Engineers. And as I read stuff like this and watch the presentations, I feel like a part of a larger community of suffering Engineers who toil away at the code, ever in search of that day when we reach developer nirvana. In search of that day when our code will mesh perfectly with the fabric of the universe, at the same time both rock solid and malleable, bending to our ever changing needs but never breaking under the strain of them. It seems that this nirvana is even harder to obtain than the buddhist kind, and the reality that is often accepted as a given is this: software sucks. Go ahead. Google it. There is some funny stuff, some bitter stuff, and some stuff that reads like a self-help book (as in “we all know it’s bad, but here is what you can do to add a little light to the world…”).
While I can relate to all of this, and I’ve certainly had many run-ins with nasty code (my own included), reading these other articles made me wonder about you, the person reading this article. Are you a Software Engineer? Are you a Software Architect? Are you my mom? Hi mom! Do you care about Software Architecture and aspire to be an architect? Or do you have more of a hands-on focus, more interested in becoming the coder that you can be? Or perhaps you are more of a “stakeholder” type — a Product Manager or Sales/Marketing/Business Development focused person, or perhaps even the CEO of your own startup. Whatever the case, I shall endeavor to write something that is pertinent to you. It is, after all, the role of the Software Architect to exist in between all of the roles listed above, and as we’ll see, to help all of these people to better communicate with one another.
I have mentioned before that Software Architecture and Software Engineering are very loosely defined fields. There is no licensing or regulatory body governing what it means to be in these fields. This past week I took a more in-depth look at that assertion, and it turns out that while there is no licensing body that bestows upon us the privilege to call ourselves Software Architects, there is a “standard” that attempts to codify what Software Architecture (or more accurately, an “Architecture Description”) actually is.
Behold ISO/IEC/IEEE 42010!
I have to say, I can think of nothing that sucks the joy out of a field of endeavor quite like “standardizing” it. Be that as it may, there are some interesting concepts that have arisen from the effort to formalize the practice. For the purposes of this discussion, the Wikipedia page on Software Architecture is about as far as I want to delve into the abyss of generalizing the process of generalizing the process of designing a software system. But that page does capture some insightful points on the nature of Software Architecture, which in turn gives us more color around the “software sucks” axiom I presented you with at the top.
In particular, the section on “Characteristics” starts off with this bullet point:
Multitude of stakeholders: software systems have to cater to a variety of stakeholders such as business managers, owners, users and operators. These stakeholders all have their own concerns with respect to the system. Balancing these concerns and demonstrating how they are addressed is part of designing the system. This implies that architecture involves dealing with a broad variety of concerns and stakeholders, and has a multidisciplinary nature.
The fact that so many people with so many competing interests have a stake in a software system is confounding enough. But what is worse is that not all of them are going to be:
- able to communicate their requirements with the needed level of specificity — not everyone thinks like a computer.
- interested in putting in the time required articulate their requirements — not everyone has the time or inclination to learn how to think like a computer.
- receptive to changing the way things have been done in the past — change means upheaval and instability in the short term, which makes jobs harder with no guarantee of future benefit.
Engineers doing the engineering is fine, and left unto themselves an engineer will be able to write code that solves a problem. But as an Engineer I personally have gone down the path of projecting (rather than truly understanding) what the end-users wants, and built it, and I’ve been way off the mark. It takes a particular skillset and disposition to be able to write good code. It also takes a very different skillset and disposition to be able to design a system that will delight an end user. And it’s very rare that one person is excellent at both, and nearly impossible to be excellent at both at the same time. There will be miscommunications, misunderstandings, and missed deadlines. There will be stress and frustration and frantic coding as the deadline nears. And unsurprisingly, there will be software that sucks.
Ultimately, it takes a larger group of people to alleviate this rampant problem, and I don’t mean more Engineers. Which roles need to be filled with how many people will be different depending on the project. But as we all know, everyone has their core skill, their “super power,” and they may have some other stuff they are good at as well. When you begin a project, you may just need a JavaScript guy who is also good at UX/UI design and a server-side developer who also happens to be a good architect. As the project grows, the need to formalize and staff other roles will become apparent. Every application has its own unique set of requirements, problems it is trying to solve, and end-user constituencies that need to be served. Again, it is the human element here that is the wildcard — the technology is the easy part!
So what is a Software Architect? Different systems will require different roles, but more than anything else, the architect needs to split his or her focus between the humans and the machines. We need to provide a bi-directional layer of empathy which will provide stakeholders with the vocabulary to communicate what they need while providing the builders with clear direction on how to build it.
As I look back on the handful of posts that I have created over the past few weeks, I see a body of work dedicated exclusively to solving business problems on the server-side. And I really have yet to lay down much code to that end, since in the early going here we’ve been focused on understanding higher order problems like what type of language to code in and what framework to choose. That is intentional. In my opinion this server-side code is the thing that needs to grow and adapt moreso than the front end. Web front ends are chaos. There is a new framework coming out every week, another twisted structure on an already overcrowded hellscape.
Throw in the fact that trends in how “modern” UI’s should look also change rapidly, and you may as well resign yourself to the fact that you’ll be changing (sometimes even re-writing) your front-end a lot over the course of a multi-year product lifecycle.
The server-side is different. It needs to be solid, and it needs to be able to grow and change as the requirements grow and change and as the business begins to consider market adjacencies and alternate offerings based on the original core. The corollary to this line of thinking is this: Software Architects should not be concerned with the web front-ends, only with providing a solid back-end for delivering business value in a front-end agnostic manner. Browsers change far more rapidly and dramatically than established businesses do. There is, of course, much room in the world for “Front-end Software Architects,” but that role would be more focused on code, frameworks, and the JavaScript community. Keeping up with new standards, frameworks, and cross-browser capabilities on the front-end (and making good calls on which to adopt) could easily be a full time job, especially in an environment where this one person’s knowledge may be leveraged across many teams.
So I would say yes, software does indeed suck, but that’s not necessarily because Software Engineers are careless. There are many more factors to consider, many more humans involved than just the ones who interface with the machines. Jerry Weinberg, a computer scientist who also happens to understand human beings quite well, is credited with the quote “things are the way they are because they got that way.” As Software Architects, we should be focused on staying out in front of that, and doing our very best to anticipate messes before they happen, eliminate the messes that can be eliminated, and compartmentalizing the messes that can’t.
