Developer Happiness

In the previous post (Insights from Software Architecture: A Tale of Two Systems), I presented a scenario where a developer used his understanding of software architecture techniques and abstractions to quickly reason about the performance of a complex system.

Briefly, a processing task was getting too big to run on a single machine, so the team undertook a major project to reimplement the same task on a scalable distributed architecture. In the end, the new system had the scalability that they needed, but it came with the tradeoff that the new system was more complex and required more computer resources to get the same amount of work done as the old system.

Many of developers in that team would gripe about the new system. Although they acknowledged that the new system was better at being more scalable, they complained that the new system was also worse because it was more more complicated, harder to test on their desktop computers, and imposed more constraints on how they wrote the code.

Interestingly, the developer who was the least opinionated about comparing the new and the old systems was the developer with the most knowledge of software architecture.

Why would that be?

The better the architecture was for delivering scalability, the less the developers had to think about scalability while implementing features.

The project is a good test case for isolating the effects of the architecture on the system because one of their explicit strategies was for the new system and the old system to produce identical output. In other words, functionally, both systems were supposed to be the same. In the new system, all the changes are in the non-functional requirements having to do with scalability.

A “non-functional requirement” refers to how a system is supposed to be, as opposed to a “functional requirement” that defines what a system is supposed to do. I share many people’s aversion to the term “non-functional” because it sounds like another word for broken. A better term is a quality attribute. In this case, the purpose of the system architecture changes were to achieve the quality attribute of scalability.

The software engineers, however, they were not thinking primarily about scalability. The new architecture was probably decided in advance by other people with the title “software architect” and presented to them as a done deal. The software engineer’s task then was to craft code to reimplement all the existing functional requirements on the new architecture.

The software engineers spent the majority of the project implementing features, while the part of the system architecture most visible to them was the set of constraints they had to work under. To the developers, the constraints seemed arbitrary and capricious, so naturally they harbored some resentment. From their perspective, the constraints were simply an obstacle to implementing features.

Except the constraints imposed by the architecture were not arbitrary and capricious. They were an integral part of the tradeoff that was inherent to achieving the scalability quality attribute that they needed. The developers, however, weren’t thinking about achieving scalability because the architecture was taking care of that for them. In fact, the better the architecture was for delivering scalability, the less the developers had to think about scalability while implementing features.

There is plenty to say about how developers can improve their craftsmanship through learning the techniques of software architecture, but in describing the scenario above, it should be clear also that there is a connection between understanding software architecture and developer happiness.

The developer most experienced in software architecture was the least bothered by the constraints because he understood what they were for. Those developers who didn’t appreciate the rationale behind the constraints just saw them as arbitrary and irritating.

Knowledge of software architecture and recognizing the tradeoffs between different architecture choices can make you a better developer, but let’s not skip over the fact that it can make you not only better, but happier.

Join the conversation...

Have you found this to be true in your experience? What have you or your organization done to help developers fit their work into the broader context? Has this made a difference?

Thanks for reading. Comments, likes, and shares are appreciated. You can find my previous LinkedIn articles here.

PHOTO: BANDAI NAMCO Studios