Developer Happiness
BANDAI NAMCO Studios

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

要查看或添加评论,请登录

David Max的更多文章

  • Said The Engineer, “Let Me Tell You a Story…”

    Said The Engineer, “Let Me Tell You a Story…”

    Have you ever found yourself reading a book, sitting cozy on the couch, only to look up after who-knows-how-long and…

    5 条评论
  • Slow Motion Change in Engineering Education

    Slow Motion Change in Engineering Education

    I wondered in my previous post, why have I met so many engineers who started out thinking that engineering wasn’t for…

    3 条评论
  • How Do You Know If You’re an Engineer?

    How Do You Know If You’re an Engineer?

    I’m an engineer, and I’ve met a lot of them. One thing I’ve noticed is that many of the engineers I know started out…

    6 条评论
  • What Makes a Good Online Group?

    What Makes a Good Online Group?

    Online groups have been around for longer than web browsers. If you're like most people reading this, you've visited or…

  • Embedding Content in LinkedIn Posts Using oEmbed

    Embedding Content in LinkedIn Posts Using oEmbed

    One of the more expressive features of LinkedIn’s Publishing Platform is the ability to embed content from another site…

    74 条评论
  • Coders Aren’t Assembly Line Workers

    Coders Aren’t Assembly Line Workers

    Clive Thompson wrote a thought-provoking piece in Wired, The Next Big Blue Collar Job is Coding. The usual definition…

    461 条评论
  • DON’T Follow Your Passion

    DON’T Follow Your Passion

    One of the most typical pieces of advice you’re likely to get for how to find a job that will bring you success and…

    303 条评论
  • The Job You Already Have Could Be The Job You Want (With a Few Tweaks)

    The Job You Already Have Could Be The Job You Want (With a Few Tweaks)

    I was sitting on a bus chatting with a couple. The husband is a software engineer like me, and his wife is a nurse who…

    64 条评论
  • What is Software Craftsmanship?

    What is Software Craftsmanship?

    I first started hearing about software craftsmanship when I started working at LinkedIn. It wasn’t a familiar term to…

    27 条评论
  • Single-Purpose Concepts, Single-Concept Purposes

    Single-Purpose Concepts, Single-Concept Purposes

    Have you ever encountered a confusing computer program? Just to take one example of many, the following question…

    1 条评论

社区洞察

其他会员也浏览了