Software Architect as Hands on… Something

One of the good things about writing is that it forces you to organize your thinking. While organizing my thinking around the role of dedicated “software architects” I actually changed my opinion. Slightly.

My original extremely persuasive argument was that the main goal of a software architect should be to minimize the day-to-day pain of the developers on the team and should therefore have hands-on involvement with the code so that the pain is felt and understood.

While reading that over, I realized it was a bit too myopic and dev-centric (sorry, I’m only human) so I broadened the goal to minimize the day-to-day pain of the cross-functional team that is responsible for developing and testing and deploying and supporting the product. After all, Architectural decisions that make things easier for those developing the product but harder for those supporting the product are most likely bad decisions. You know, the whole “optimize the whole” concept that goes all the way back to the Toyota Production System.

So then, I guess a good software architect would be someone who still feels the day-to-day pain of their architecture decisions as an actual hands-on-contributor to the cross functional team, regardless of discipline. Ideally it should be someone who has gone through at least one cross-disciplinary crop-rotation.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: