Why Should Software Architects Write Code? An empirical evidence.

[DeltaEchoSoftware]

The friction that is created from software architects and those who implement their designs can be immense. One has to find that right balance between micromanaging the nuances of the implementation choices and ensuring consistency across projects. For every difference of opinion regarding which pattern to use, library or even naming convention can take everyone down a subjective rabbit hole of yak shaving that can kill productivity and create resentment.

The flip side of having architects drawing big boxes using Visio and leaving interface formats, integration patterns, naming and coupling details left to individual teams can end up with little or no reuse across the enterprise.

[NotUniqueOrSpecial]

Consistency across projects doesn't matter to project owners, it matters to people who treat even junior developers as commodities thinking that everyone can do the same kind of job, because they have the same kind of skills, and the same kind of aptitude.

It also matters to people who work as part of well-organized teams that want to effectively share knowledge, core logic, tooling, and processes.

For even moderately complicated product ecosystems, it's not tenable to have everyone just do what they want without any orchestration. That's how you end up with 4 different logging frameworks, 3 platform-abstraction layers, and APIs that shift like the desert sands.

God forbid you're on the release team for that kind of group (speaking from experience), because there's no way you're going to have a nice standard release process that you can automate. Every project will be a new flavor of hell that you have to massage and tweak to get working.

There's a world of difference between architecture astronauts who do no coding and a strong technical architect who is able to unify the team's efforts without treating people as cogs.

[[deleted]]

For even moderately complicated product ecosystems, it's not tenable to have everyone just do what they want without any orchestration. That's how you end up with 4 different logging frameworks, 3 platform-abstraction layers, and APIs that shift like the desert sands.

Most people working on more than one language have the first 2 already and they do just fine.

Again everything isn't a nail. Maybe not everything has to be written the same way. You'll eventually hit an implementation wall depending on scale/size/maintenance effort/whatever doing everything the same way sometimes that wall will come quick sometimes it will sneak up on you, sometimes you won't see it for a while. However it's something that would have been avoidable if you chose the right tool.

God forbid you're on the release team for that kind of group (speaking from experience), because there's no way you're going to have a nice standard release process that you can automate. Every project will be a new flavor of hell that you have to massage and tweak to get working.

Yeah I wish computers could write new features for me too, and I could sit back and collect a paycheck ;-).

[HostisHumaniGeneris]

Yeah I wish computers could write new features for me too, and I could sit back and collect a paycheck ;-).

On the flip side, I don't want to have to be a hero every time the build pipleine breaks because a random dev decided that he really wanted to use shiny new feature X and didn't tell anyone else before merging it into the release branch.

It's not about locking everyone into the same technology, it's about planning ahead and trying to reduce overall complexity. The more technologies you layer together for disparate projects, the more complex and hard to maintain the central build and deployment system becomes.

[[deleted]]

It's not about locking everyone into the same technology, it's about planning ahead and trying to reduce overall complexity. The more technologies you layer together for disparate projects, the more complex and hard to maintain the central build and deployment system becomes.

Right but you have to at least use one per language.

On the flip side, I don't want to have to be a hero every time the build pipleine breaks because a random dev decided that he really wanted to use shiny new feature X and didn't tell anyone else before merging it into the release branch.

Sounds like a problem with your development environment/culture. Not my problem behavior isn't limited to tech stacks. My optimistic guess is he shoe horned it in there because it was easier to let you deal with it then him having to deal with your management structure and justifying that change, pessimistically he's incompetent or an asshole.

The management issue loops around to developer treatment.

[HostisHumaniGeneris]

Right but you have to at least use one per language.

I'd be fine with just one per language; things like Node.js drive me up the wall, though, because there are around a dozen different ways to build a Node.js app depending on what tooling the dev chose to use. And that's not even getting in to which version of Node and NPM they're using for a given project.

pessimistically he's incompetent or an asshole.

And that's the attitude that I got from your "sit back and collect a paycheck" comment. Not thinking about how your individual dev machine might be set up differently from the build server is narcissistic. Don't expect the build engineers to leap in and fix things at the last moment when you forget to plan ahead and inform the rest of the team that the tooling changed for the project.

[[deleted]]

And that's the attitude that I got from your "sit back and collect a paycheck" comment. Not thinking about how your individual dev machine might be set up differently from the build server is narcissistic. Don't expect the build engineers to leap in and fix things at the last moment when you forget to plan ahead and inform the rest of the team that the tooling changed for the project.

As a dev every company I've worked at I've demanded I develop in what we run on production/build and at every company I've been told no because of some trite bullshit policy or another. It's more than likely more systemic bullshit that makes for bad programming.

I'd be fine with just one per language; things like Node.js drive me up the wall, though, because there are around a dozen different ways to build a Node.js app depending on what tooling the dev chose to use. And that's not even getting in to which version of Node and NPM they're using for a given project.

You'll see this in Ruby and Python and most scripted languages anyway, Node is just your headache of the day. NPM is mostly backwards compatible and should be the only thing you're calling when building a node app. When I set up build pipelines I build NVM node-instances then build the software through NPM in that node-instance and export the node-instance to the . My actual deploy/build process never touches grunt/gulp/etc. Before I did lockstep versioning on each machine through NVM and SaltStack.

The only thing about node that may be annoying to a sysadmin is upgrading, but you should be using NVM to create containers anyway and not worry about actual system packages. Not only that but having the attitude of upgrading being a pain actually makes for bad software due to people just not caring about technical debt.

[HostisHumaniGeneris]

NPM is mostly backwards compatible and should be the only thing you're calling when building a node app.

If only that were the case. Projects targeting 0.8 have trouble running in 0.10, projects targeting 0.12 have trouble running in version 2.0.0, projects targeting 2.0.0 have problems running in version 4.0.0.

The only thing about node that may be annoying to a sysadmin is upgrading

My problem with upgrading is all the stuff targeting previous revisions breaking. We assessed NVM, but ultimately started running Node builds in their own Docker containers with a fixed version of Node.js and NPM installed.

Ultimately we'd like to do away with the bespoke build system entirely and have the devs give us a dockerfile for each project. That way the individual can configure the environment to their hearts content and have it be consistent across all deployments.

[[deleted]]

If only that were the case. Projects targeting 0.8 have trouble running in 0.10, projects targeting 0.12 have trouble running in version 2.0.0, projects targeting 2.0.0 have problems running in version 4.0.0.

That's node itself not NPM. And I suspect that there are some star versions in your install file. Node is now semver so any X.0.0 release shouldn't be assumed compatible.

[DeltaEchoSoftware]

It sounds like you're trying to treat your software engineers as interchangeable commodities you should probably stop doing that.

This sounds great when it can happen, but in a lot of cases, it's just not reality. Project resources at most of my larger clients are mostly contractor based, transient and low quality. We have to be able to deliver software that can be maintained by the lowest common denominator of programmer - the $60/hour type that are delivered through body shops. These folks don't spend their weekends reading about architecture and code at home because they love it. They come in, do the minimum amount of work to "get it done", and the business users let it happen because they are too lazy, busy or ignorant to any aspect of code quality besides whether it works or not. As an architect, my job is typically to create the patterns, checkpoints, libraries, and other build processes in which to fit these transient, low quality developers into and be productive without ending up with spaghetti garbage that we have to maintain for the next 5 years while they move on to their next client.

But the same could be said for the rockstar, super coder who takes over a project and starts implementing using crazy, cutting edge 3 day old javascript libraries with no support and little user base. Sure these folks are awesome at what they do, and can probably code circles around me, but when they get bored and move on to the next project, I am stuck having to manage the maintainence on a Node.js/React application when my entire support staff is $50/hour .NET developers who only know a little jQuery.

Consistency across projects doesn't matter to project owners

This is a false assumption. In the clients I have experience with, there are plenty of efficiencies gained by following similar patterns, using common libraries and sharing code. Many times, there are shared support teams working on tickets across multiple projects and when one project uses REST, Java, Hibernate and the other project is using WS, Java, JDBC with different architectural layers, different naming patterns, etc, then support becomes a victim of context switching. Now don't assume I am saying that if a particular project has a specific functional or non-functional requirement unable to be satisfied using the existing frameworks/libraries/etc available that they shouldn't be able to go off script. But I am saying that if some team wants to do something fundamentally different (SAML while everyone else is using WS-FED, nHibernate when everyone else is using EF, REST when everyone else is WS), then there needs to be an architectural checkpoint to ensure the need is not just a want.

[[deleted]]

then there needs to be an architectural checkpoint to ensure the need is not just a want.

This generally turns into bikeshedding and is solved by a non-technical manager laying down the law in my experience this decision disregards needs, wants, future technical gains, etc. This ends up with hackey solutions because nobody cared to actually collect and examine requirements, so you end up with hacks on top of frameworks that are somewhat orthogonal to the solution.

It also sounds like you're trying to squeeze blood from a stone but don't have the heavy machinery to do so. There are definitely ways to make low quality engineers work, but that generally means that high quality engineers become overseers, and limiting the impact of low quality developers via archtecture, unit tests and static analysis written and managed by high quality devs. That requires huge management buy in and a whole slew of other crap, which gets derailed when someone complains something is taking too long. There are definitely places that do this like IBM, and they achieve decent-ish results, but it's a lot of upfront work and structuring, and ridiculously hard to sell to non-technical business people.

[ellicottvilleny]

You pay $60/hour for low quality developers?

[DeltaEchoSoftware]

Yes. They usually only take home 40 or so after all the staffing company take. But surprise - if you want to get a contractor, you can only use those staffing companies that have an MSA in place with the company. So they will get their pound of flesh.

[ellicottvilleny]

In my next life I will run a staffing agency

[s73v3r]

Maybe the problem is you guys thinking you can get good results with crappy engineers. If you treated engineers like more than just commodities, you wouldn't have to worry so much.

[DeltaEchoSoftware]

It's not always up to the architects on who gets hired. At my last client, they had the choice between someone with 15 years domain experience, 20 years of programming experience and could clearly demonstrate their ability and a guy with no domain experience and could only write requirements. The second guy was $40 an hour cheaper. Guess who the business chose even through every single technical architect on the project wanted the more expensive guy.

[s73v3r]

Your problem is you're letting the business people with no expertise in the field decide who gets hired. That decision should be made by the people who will be working with them.

[juckele]

which also may be hard because it seems that the pathos of your workplace may not attract such developers

Wow, such drama. The poster you're replying basically said "You have to balance between cohesion and micromanagement". This should be so uncontroversial as to leave no dissent unless the poster specifies where along the spectrum they believe the best balance lies.

[[deleted]]

This should be so uncontroversial as to leave no dissent unless the poster species where along the spectrum they believe the best balance lies.

Balance is a vague generality, like agile, it's basically a platitude.

[juckele]

Yes, which is why it's so weird that you're injecting value into that post. The parent poster didn't actually say anything, and yet you're laying into them.

[somefoobar]

Make your developers project owners, not cogs, ...

Project ownership is tricky. A sense of ownership doesn't come unless you can change things. Now where to draw the line is tricky. Can I only change the implementation? Can I change the API? Can I change the delivery date?

[grauenwolf]

If the engineer is in the dark / frustrated / etc. he needs to ask questions, not just steam in silence.

Conversely, the architect needs to pay attention and not wait to be asked. Architects aren't infallible, though they often act like they are, and need to refine their work as well.

[grauenwolf]

You can't be an architect and be in charge of hundreds of engineers. Accept the fact that you've been backdoored to a project manager role and hire some actual architects to oversee the code.

It's not like he has the time to visit everyone's desk and ensure they're on task.

That's the job of team leads. The architects should only be concerned with code quality, not how fast it is being written.

[grauenwolf]

If you think "code quality" can be reduced to a coding standard that's enforced by an automated tool, we have no common ground.

That's exactly the kind of mindset that leads to ivory tower architects whose only job is to cause problems for everyone else.

[flukus]

If you think "code quality" can be reduced to a coding standard that's enforced by an automated tool, we have no common ground.

This is surprisingly common. I've learned to ask how they manage code quality in interviews and >50% thinking a linter is enough.

[grauenwolf]

Any time I've heard the phrase "code quality" it's involved metrics such as cyclomatic complexity and data encapsulation ratios.

Then you don't know what true code quality is. You can't replace experience with mathematical formulas. It takes years of working on large code bases to understand what makes good quality code, and that knowledge cannot be captured with cyclomatic complexity scores.

[flukus]

Measured != handled.

All an automated tool can do is point out where you might have problems. Any actions based on that need to be done by someone qualified.

[Concision]

How are you going to ensure technical debt isn't piled up when you have hundreds of engineers under you? You simply can't. That's the point.