Fight For The Architecture

Published 25 January 2018

I’m currently reading Clean Architecture by Uncle Bob. I’m still pretty early on in the book, but I just read a section that made me need to put it down and write this post!

Developers are stakeholders too

In a section titled ‘Fight For The Architecture’, Bob talks about the ongoing struggle of fighting for what you as a developer and/or architect believe is right for the company. Just as the management team, marketing team etc also do. The part of this section that really stood out to me was this:

[Effective software development teams] unabashedly squabble with all the other stakeholders as equals. Remember, as a software developer, you are a stakeholder. You have a stake in the software that you need to safeguard. That’s part of your role, and part of your duty. And it’s a big part of why you were hired.

This, so much this! I think this is something you don’t tend to recognise early in your career, at least I know I didn’t. I also think that if the company doesn’t recognise their development team as a stakeholder, it’s a steady slope to a product that will eventually fail. Without time spent on the architecture, you’ll end up with a product that’s more and more difficult to add to and maintain. You’ll have to add more people to the team, but your output won’t increase because the code base is harder to work in every day. Every line of code gradually gets more expensive to write, but your output will no longer match your investment. Eventually it’s going to need to be rewritten or abandoned.

In my current job, I really think we’re getting this right so far and I’m going to keep working at it to keep it that way. We’re building an amazing culture and team and I’m pretty damn proud of what we’re doing.

So for the developers reading this, remember, a software development team is definitely a stakeholder in the product they are developing. Sometimes we have to stand up for something for the good of the product and help make the other stakeholders understand why it’s important. We are in these positions because we understand the technical implications and because we’re good at what we do. If you sit back and let things go, you’re going to end up working in a mess of code that’s definitely not fun to work on and is challenging for all the wrong reasons!