Add a comment


Re: Re-evaluating software architecture

Hi Kevin,
I'm not sure I'd go so far as to say that they're the same thing because that might give the impression that architectural activities and development activities were the same or required the same skills.
Really? I wouldn't say a programmer was fully qualified to program unsupervised if he didn't have a good appreciation of architectural concerns. Why? Well if he hit an issue that was architecturally significant, he wouldn't know. So architecture is part and parcel of programming IMO.
My worry is a team that becomes an XP steamroller and ends up thinking that everything is merely an extension of development because "it all ends up as code".
Whether you call it a steam roller or not, it does all end up as code. At the highest level of abstraction there are only two roles: people who commission software and people who produce it.

A great number of very successful systems have been produced by teams with just these two roles. In fact the most successful systems have been produced when these roles have been combined into single role: customer/developer. Unix is a good example of this, whether we talk about Thompson and Ritche, Bill Joy or Linus Torvald. Emacs and Richard Stallman is yet another example.

There is a reason. The more roles, the greater the number of hand-offs and the higher the communication overhead. With fewer roles, there is less scope for misunderstanding and shorter feedback paths. With only one role, feedback is instantaneous.


Re: Re-evaluating software architecture

HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
E-mail address
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).