Code as Design: Implications for Architects

{

I've just got to Jack W. Reeves thoughts on Code as Design in his seminal article originally in the now defunct C++ Journal, and now republished on developer.*. I really liked his thoughts and although I can't necessarily say it's been something intuitively sitting in the back of my mind, its implications are definitely something I've thought for a very long time.

The basic premise of his article is stated early: final source code is the real software design. From the source code design specification, a compiler and linker do the manufacturing work to implement the software from what one could term the design document of source code. He continues to discuss some implications of this that are well thought out and, from my experience, very true.

A great thing about the article is the return to the notion of engineering and software development being treated together. These days I see a lot of writing about how the words software and engineering could never go together, but as Reeves shows, there is a very real relationship between disciplines especially if we think of our code as a design document.

But the real implication for me, beyond the ones stated by Reeves, has to do with the title "Software Architect" - which I happen to hold (not overly meaningful, by the way - everyone at my company is a "Software Architect"). People with the title, who wield Visio, Use Cases, and management-speak exclusively, aren't the real architects of the system. Of course these tools are very useful, and of course general direction is always necessary for a project, but for the notion of a real "Software Architect" one has to stay close to the code - close to the actual design document - to really shape the manufacturing process. Although staying close doesn't mean, to me, writing every line of code oneself, it means understanding and being a part of the process of making it.

}