Microsoft .NET: Architecting Applications for the Enterprise ... - BattleIT

Chapter 1 Architects and Architecture Today 23
Another school of thought thinks, instead, that every architect is a born developer. To take
the metaphor one step further, we could say that the class Architect inherits from the
class Developer and adds some new methods (skills) while overriding (specializing) a few
others. Becoming an architect is the natural evolution in the career of some developers.
The basic differences between an architect and a developer are experience and education.
You gain experience by spending time on the job; you earn your education from studying
good books and taking the right classes. In addition, an architect has the ability to focus
her vision of the system from a higher level than an average developer. Furthermore, an
architect has good customer-handling skills.
An architect might not write much production code. But she writes a lot of code; she
practices with code every day; she knows about programming languages, coding techniques,
libraries, products, tools, Community Technology Previews (CTPs); and she uses the latest
version of Visual Studio or Team Foundation Server. In certain areas of programming, an
architect knows even more than many developers. An architect might be able to write tools
and utilities to help developers be more productive. And, more often than you might think
at fi rst, the architect is just a member of the development team. For example, an architect
writing production code is an absolutely normal occurrence in an agile context. It is also a
normal occurrence in small companies regardless of the methodology. At the same time,
an architect who writes production code might be an absolutely weird occurrence in some
large-company scenarios, especially if a traditional and non-agile methodology is used.
What about the two of us? To which school do we belong?
Well, Andrea is more of an architect than Dino because he lives on the fi fth fl oor. Dino,
on the other hand, is closer to development because he has quite a few highly technical
ASP .NET books on his record and, more importantly, lives on the second fl oor. We don’t
play golf, though. Dino plays tennis regularly, whereas Andrea likes squash better. We just
have been denied access to the fi rst school of thought.
Note In no other area of engineering is the distinction between those-who-design and
those-who-build as poorly accepted as it is in software. The distinction exists mostly through
postulation rather than fl owing from a public recognition of skills.
The canonical comparison is with civil architecture. Bricklayers have their own unique skills that
engineers lack. No bricklayer, though, will ever dream of questioning designs or calculations, simply
because the bricklayer lacks the skill to make the decisions himself. Bricklayers do their own work
the best they can, taking full advantage of having the building work delegated to them.
In software, the situation is different because architects and developers have common roots. The
more skilled a developer is, the more he feels encouraged to discuss design choices—and often
with reason. The more the architect loses contact with everyday programming, the more he loses
the respect of other developers. This generates a sort of vicious circle, which magically becomes
better as you switch to an agile methodology.