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.
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!
Cover photo by sydney Rae on Unsplash
Top comments (17)
In a manner of speaking, this is what so many software developers are looking for in a company they might work for. Hiring folks don't always do a great job of expressing differentiations their org might offer in this regard.
There's always going to be a challenge of balancing needs, but the state of it having to be a fight is pretty sad and I'm definitely going to try and outline this in future attempts to describe what working with us could be like.
I agree. I’ve worked in places in the past where it was a fight which was why I think this part of the book stood out to me.
In my current position, I was the first person in the development team so as I’m building the team and culture, I’m making sure it’s an integral part of what we do. As a start up we have to move fast sometimes, but some things are worth slowing down for. I try to empower the rest of the team to feel like they can always speak up for something they believe in 🙂
That's great to hear!
I'm always surprised at the longevity of culture. What you establish today may still be close to the corporate DNA of the company 50 years from now. You are sowing the seeds of the future. (I'm a bit envious!)
And from Uncle Bob's Clean Code book... the only way to go fast is to go clean. ;-)
One company I used to work at had a change of executive leadership. One of the first things the new leadership did was to charter a new course and instill some dramatic changes to the existing culture.
The ship is turning... ever... so... slowly. After 4 years, my friends that still work there say there has been very little actual change in 4 years. There has been some, but at the current rate of change it may be decades before the new executives' outlined vision is fully realized. Decades.
Change is hard. Organizational inertia is hard to tackle. Six Boxes looks into the sociology & psychology of trying to change a culture. Corporate antibodies, organ rejection (i.e., ignoring executive edicts), and backsliding to the comfort zone of the old ways all act as anchors holding back change.
I feel very lucky to be given the opportunity and the trust to lead the culture for the development team :) It's my chance to put into practice all the things I've wanted to see in my previous companies I've worked in.
I've worked at places previously that have been trying to change their culture and seen the same problems you've described. It can take a long time, and in some cases it may never reach their envisioned finishing point. It's still nice to see companies at least acknowledging changes to their culture are required and trying to change it though.
I might be wrong, but doesn't doesn't the idiom go like: "In a manner of speaking"? I am not trying to be a jerk, I am just curious as I am not a native english speaker.
You're right. I'll fix it 🙂
This topic is so important, I'm so glad you wrote a post about it!
To extend on this, it's often the case that the development team won't get their way in regards to a certain architectural decision, and that's a-ok.
In those cases, things like Architecture Decision Records become invaluable.
The simple act of documenting a decision, it's impact and it's consequences for reference down the track is a great way for a development team to gain trust and build a stronger case for architectural decisions down the line - among many other things.
I was recently involved in some discussions around some serious technical debt a team I was working in had to clean up in order to broaden the usefulness of one of our products. The debt itself was the result of an ancient architectural decision that was documented in an ADR.
Initially, the other stakeholders were very reluctant to accept that we had to spend significant time on straightening things our before we could proceed. Then we presented the original ADR, including the consequence "if we want to extend Y in the future for X purpose we'll need to back away from this architecture in favour of Z. The long we build on Y with it's current architecture, the more expensive moving to Y will be."
The folks in the room immediately remembered the original conversations. They remembered that we made a deal at that point in time, that if they wanted to do X, this would be the cost. Ultimately we got to give the system the love it needed and our stakeholders were satisfied that this was not just necessary, but valuable work. Everybody wins.
When it comes to architecture, sometimes it's ok to lose a battle today to win a war later on. Just make sure everyone has a way to remember the impact of the initial battle.
Side note: I agree with Ben that it's super sad that these types of decisions need to be fights (and now battles and wars, thanks to me). Why can't all us stakeholders just get along? ❤️
This is a really good point about decision records. As the Systems Architect at a start up, these are conversations I'm having regularly. I'm not currently documenting any of them but your example clearly shows why I should be. Definitely going to start doing that!
The idea to fight for the architecture means take ownership for quality and user experience of your area... don't just blindly implement whatever is asked. Investigate, negotiate, and if necessary once in a while even say "no" to requests. @ben this might go without saying (to protect the quality/user experience) when you start your own company. But this is a strange concept to juniors and business devs in general. For the latter, most companies treat you simply as a gear that turns the software wheel, so you feel equally dispassionate to the software you create. "Just doing what I was told." Over time it becomes a mess because no one cared enough to understand what they were actually coding, only how to technically accomplish what was asked of them. As a junior dev, focusing on the technical part is kinda where you have to live for a while until experience teaches you enough about the business to know when a request is going to actively harm quality or UX. This is why apprenticeships/mentorships are especially useful.
I have an example along the line of "fighting for". A customer stakeholder asked us to add a field to keep some information. But then we started to think about how someone would actually go about using that information for its stated purpose. We saw it was going to be very awkward and would probably never be used. So instead we brought an alternative idea to the customer. It was a little more work to implement, but it directly addressed the problem they were trying to solve. They loved the idea and we implemented it instead of the original request. Turns out other customers really like it too, and we've had followup requests to add a few more options to it.
Yeah I totally agree. This sort of thing goes without saying for me, but is absolutely not what I've observed. The fight is the more typical scenario, which is not ideal. An ideal would be that all parties understand ahead of time that this is the reality, so the "fight" stops being a fight and ends up being a mutual collaboration. Other problems might prop up, but we address the fight by making the stakeholder reality a core part of the work and use it as a hook to hire talented and empathetic engineering candidates.
I agree, mutual collaboration is the best way. "Let's work together to do our best for the user/customer." However, it is an impressive feat to consistently hire people who hold to that. Even then I think gets harder to stay that way in larger teams. When things are small everyone is more individually connected and accountable to everyone else. I like working in my smaller team. :)
A friend of mine is experiencing this exact steady slope to failure even thou he did all he could to convince the company to approve his improvements to how the team works and rethink how much workload they can handle.
Somehow his team (handful of ppl) is now working on 8 projects "in parallel", undocumented and poorly designed projects, he decided to quit in a few months and leave the company with this enormous debt as a wake up call, the funny thing is, the company is well-organized when it comes to other departments (by design), the IT department is kind of new, but idk why they're neglecting it and now blaming them for pushing the deadlines o-o!
I feel for your friend. It's difficult and frustrating when you keep hitting a brick wall like this. Good for him on trying to show them how to change though. It's such a shame they won't try his suggestions.
Hopefully, for the sake of all the people working in that IT department, they start to trust the people they've hired to be their experts soon.
Alas departments are tribes, and tribalism is always us vs them. Good management realises you don't win by accident, you win by design. And you start by designing a project team with representation from all stakeholders.
In 32 years of consultancy I've always been proud to fight for good systems architecture in every client company we've ever served. One of our founding tenets is that we will save clients from themselves. It's earned us a reputation among clients for straight talking, looking after the interests of the (their) business, and refusing to line our pockets for short term gain. Merely because the client puts their throat into your mouth doesn't mean you should bite.
Alas you'll find lots of people mistaking systems architecture for "this is how you lay out your project" on here and elsewhere. Systems architecture is important and deserves study and practise. Because without a solid architecture any construction project is doomed to failure.
In my experience while working with clients, it's really important to make yourself present. The developer experience counts more than any feature a client might need (if they even know what they want).
This reminds me to the most accurate video of software development.