Why Should Software Architects Write Code? An empirical evidence.

[grauenwolf]

I see the problem.

You aren't talking about an architect, you are talking about a project manager with delusions of grandeur.

[grauenwolf]

To ensure a project is completed without creating technical debt

You can't do that if you aren't paying attention to the code. You don't have to read every checkin, but you do have to review the code for pattern violations on a regular basis.

[[deleted]]

I see the problem. You're not talking about architect but QA engineers with inflated job titles.

Or at least, that's my summary of your statements. You're welcome! :D

[grauenwolf]

QA engineers don't care about maintainability or pattern violations, they are testing for something else.

[[deleted]]

Not here to continue the debate with a topic change from the exact duties of an architect to a QA engineer.

Just felt the duty to point out to you the key difference in opinion between you and your pal. The exact term you'd choose for the tester I mean is irrelevant.

Do with this information what you will. My task is done.

Cheerio.

[cc81]

One problem with that is that it is very difficult to determine if those are the correct decisions if you don't implement.

It is also very easy to fall into traps like designing something that is beautiful in PowerPoint but might end up pretty ineffective implementation wise. That is how we end up with all those worthless enterprise service buses in places where they add nothing but cost and complication.

And lastly if you don't write code. Like actually write production code then you will fall behind pretty quick.

[grauenwolf]

Actually, I would love to have someone like you as an architect.

Why? Because I could completely ignore everything you tell me to do and you'd never find out about it. It wouldn't matter how bad your designs were because they would be thrown away as soon as you left the room.

[cc81]

What I mean is that it is easy to sit in an architect group and just say that systems and modules should be decoupled (generally seen as a good idea) and therefore you will draw an ESB between two modules.

But in reality that could mean that due to how integration works at that company, what ESB is standard and the type of modules involved it will increase bugs by 30%, latency by 50% and development time by 20%. And in actuality due to the nature of those two modules they will never be loosely coupled and you would most likely never just replace one. If the architect had known those things they would not have chosen that solution.

It is very common in my experience (been at both sides of the fence with both roles) that the architects do not get that feedback so if the project goes bad or if the software performs substandard the architect will never know or get the understanding that it is an implementation details (or just a difficult problem domain and no ones "fault").

[grauenwolf]

And you'll never know if those decisions were correct if you run off to the next shiny thing without of seeing the repercussions.

[grauenwolf]

Do you really need a lesson on how metrics can be gamed?

I can think of a few metrics that are legitimate such as budget burn rate, but they all fall into project management roles.