Disclaimer: this may be be a Seattle area phenomenon.

I have “software architect” on my resume, and it pains me. Wikipedia has a great article on what a software architect may or may not be. But, in my world, a software architect has the knowledge, insight and responsibility to make educated decisions about the scope and direction of a team-developed software project.

That was a mouthful.

Software architects pick frameworks. They find previously existing packages for functionality just before the rest of the team realizes they need it. And, they plan and communicate how all the moving parts will come together. They’re really-really smart.

Everyone wants to be a software architect. At Seattle’s Startup Weekend, no less than a third of the developers signed up as architects. And why not?! The act of creation - from art to programming - is egotistical. If you’ve ever referred to yourself as a “software engineer” with a straight face, then you’re advertising the capability to plan non-trivial projects.

You’re a liar.

Software is big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to software.

With all apologies to Douglas Adams. Software projects are the most complex machines created in the history of invention. You’re telling me that you can do better than Leonardo Da Vinci, Thomas Edison, or the Wright Brothers? Because each of those iconic figures were geniuses driven to create simpler machines than a web application. And each was wrong up front.

This isn’t a fair comparison. We have Photoshop, Digi-Key, and kit airplanes. Also, Rails!

Those inventors were forging into unknown territory. Customizing a CMS or integrating SAP ERP into a SOA are known quantities. It could be argued the architect exists for the partially ambiguous problems.

My response is a question oft head in agile circles. I learned it from working in open source projects, corporate giants, startups and contracting. It’s a kōan:

“How will your program work in six months?”

The job of software architect is an answer. Is it the right one?

• There is value in understanding a problem domain.
  But, the stakeholders in a project tautologically have that.

• There is value in making the hard decisions.
  But, that is why we have team leaders.

• There is value in planning your design.
  But, software structure inevitably resembles its team’s structure.

… and so on.

The software architect exists because of the cultural need to have someone be responsible for these aspects. But it isn’t possible to satisfy these responsibilities and simultaneously attend to the details that inform future decisions. Architecture astronauts just don’t have the time to be any more grounded!

Instead? Go slow. Let the programmers make the decisions. Feed them knowledge and constraints. Try to develop a consensus among the actual stakeholders. And accept everyone’s input. That quiet intern? They go home and spend all their spare time playing with tools that handle 80% of the job.

I’m not arguing for agile development practices.

I’m arguing for considered diligence. Plan a little. Work a little. Rinse and repeat. Never let yourself slip into the tunnel-vision that comes with long cycles.

Because if your team cannot make responsible architectural decisions, then no one can save your project.