The Old Joel on Software Forum: Part 3 (of 5)

The Architect Within

I read recently, perhaps here, that the process of trying to reuse code ultimately results in the creation of a framework.

I thought that was a pretty good insight since I think it's true.

It led me to come up with a test for who is an architect, a question that's come up before.

As I see it, creating a framework is really an essential part of being able to do architecture and it's the think that distinguishes the coder from the high level designer. If you've never created a framework, you can't really understand all the issues that come to play in being able to impose an intentional structure on something, as opposed to just hacking along until it's done.

So... You're an architect when you finish your first complete framework.

That's not enough of course, you might need to create a second one before you really know what you're doing. But having created a framework, you have the right to call yourself an architect.

Dennis Atkins
Monday, October 6, 2003

"Who needs an architect?"

http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

---> Architects are leaders that help less experienced coders to make good decisions themselves - much as a senior member of the faculty advises and coaches a junior member of the faculty at a large university.

When it becomes about power, prestige, and position, then you've got a problem.

JMHO ...

Matt H.
Monday, October 6, 2003

Dennis,

I think my definition of an architect is different to yours - not better or worse, just different. Recently, we've been working on a new shrink-wrap software product. Up front, we had three product development roles:

1) Architect: Decides who the customer is, and what his goals are - sets the product vision and its strategic direction - analyzes the competition and decides the USPs.

2) Designer: Designs the architecture that will implement the architect's vision - specifies the level of quality required - designs the UI - keeps track of project risks.

3) Engineer: Builds the product conceived by the Architect and designed by the Designer - ensures that the product implementation works in the real world - ensures that the implementation is done with the specified quality - makes buy-versus-build decisions.

So I think my Designer would probably equate to your Architect. Note that these roles are very fluid in my company. Everybody doing any one of these roles is expected to have a good understanding of the other roles. In fact for this product, all of the people actually do some of the coding. There's nothing quite like having to implement one's own grand ideas to bring an architecture astronaut back down to earth :)

Mark
----
Author of "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128

Mark Pearce
Monday, October 6, 2003

Mark, I think what you've called an architect is actually a sort of Business Analysis role.

I think what you call a Designer is in fact the Architect.

Gwyn
Monday, October 6, 2003

Are the terms "Architect" or "Software Architect" used more as a reference for distinguishing/compensating the most experienced developer on a team? It seems that it is used more for the benefit of non-IT folks in an organization (i.e HR, VP's, PHB etc). If you try to explain what the "architect" does to these folks, you'll usually get a glazed look, but if you say, "Joe Blow is the software architect", that gives the higher ups something they can grasp (i.e The architect is the lead dude/dudette on the team).

My very deflated $0.02

Cletus
Monday, October 6, 2003

The difference between Architect and Designer or Analyst is around 20% extra rate per hour.

Or if they really don't know, 50%.

Simon Lucy
Monday, October 6, 2003

"1) Architect: Decides who the customer is, and what his goals are"

No, the customer decides what his goals are, the architect incorporates those goals using personas to design the application/system. The programmers construct it and users use it.

Interaction Architect
Tuesday, October 7, 2003

>> No, the customer decides what his goals are, <<

Most customers haven't got a clue what their goals are, even when prompted. The architect has to construct the goals from their random ramblings.

>> using personas <<

Only if you stick with Alan Cooper's view of the world. In case you wondered, we don't :)

Mark

Mark Pearce
Tuesday, October 7, 2003

That's why you need to observe what users do - not ask them. As Jacob Nielson says:

"what customers say and what customers do rarely line up; listening to customers uses the wrong method to collect the wrong data"

Interaction Architect
Monday, October 13, 2003