Architects Must Write Code


I had the opportunity to read Practices of an Agile Developer: Working in the Real World. The book has 45 tip to help developers become agile. And, it's clear that Venkat and Andy know the problems of becoming an agile developer, because along with each tip, there's a devil-thought to show people what happens in the real world. There are also angel-thoughts to show people why this tip works.

My favorite tip, and something I've been saying in my assessment reports for the last 10 years is “Architects Must Write Code.” (p. 155 in this book.) Venkat and Andy say this about ineffective architects:

They typically come in during the beginning of a project, draw all kinds of diagrams, and leave before any serious implementation takes place. There are many “Powerpoint architects” out there, and they aren't effective because of lack of feedback.

I've been a part of projects for 30 years. I've been assessing projects for 10 years. And every time I've seen an architect who doesn't participate in the code-writing part of the project, I've seen an architecture that doesn't do what it's supposed to do, never mind extend to inevitable changes in requirements that occur during the project.

Architects need feedback about their architecture. The only way to get feedback is to write the code, integrate it, and see what happens.

33 Replies to “Architects Must Write Code”

  1. Hi Johanna,
    Can’t get this one go. I disagree with the title.
    If you said “architects must seek feedback”, then I’d agree. Writing code is one way to get feedback. It can be a good way, but there are others. For example, architects can participate in project reviews and retrospectives. They could find other ways to listen to the people writing the code and learn from them.
    In many projects, writing code isn’t the riskiest part of the job. Sometimes user interface design is. Sometimes testing is. (I worked on one project that had a horrible architecture by pretty well every criterion except that it massively reduced the effort required to assure functional correctness of the system. On this project, an architect would have learnt most by writing acceptance test cases.)
    I think good architects identify where the biggest technical risks are likely to be, think about ways to mitigate them, then follow through to see how well those solutions worked.
    PS I’m getting tired of the campaigns against “powerpoint architects” too. Architects often need to communicate to diverse audiences – helping non-technical people understand what they’re getting into as well as technical. They should be choosing tools that help them communicate to the relevant audiences. Powerpoint can be a good tool for some audiences. (I agree that for developers, it almost certainly needs to be backed up with other tools.)

  2. I also heard many times from very prominent gurus like Frank Buchman that architects “must write code”, and I tend to agree with Graham: it depends. Any architect should be technically capable, that’s for sure. However sometimes being a good communicator and/or just a person who is capable of grasping a big picture is more important than writing a cople of lines of a plain code. It also depends on whether the project is a “pure” agile or not. In the latter case the rules of the game can be significatly different.

  3. I believe that this pattern, called “Architect Also Implements”, originated some years ago with Jim Coplien. I don’t have an original reference to it, but as far as I know he’s the first person who ever wrote this notion down.
    As for whether architects /should/ write code, I believe that they should. They need to eat their own dog food.

  4. One sure way to know if your design is worth anything is to be involved in the maintenance of the application. Any slick kid off the streets can code something that will ‘compile and run’ in the development environment. Great design and code also perform well in production!

  5. Anyone can speak about theory, but from my 20+ years of practical experience, I have only seen successful software architecture done by someone who was involved in the coding.

  6. Would you force your engineers to weld the frame of a car they designed? No. Because it’s not what they do with excellence. However, I would agree the engineer should review said weld and confirm it was implemented to spec. If it’s not, perhaps there is something to learn. The welder might say, “It’s not exactly how you designed it because this method yields a stronger weld–one which will support the load.” Engineer: “Sweet! I’ll use that on my next project. Thanks.”
    Similarly, I think software architects should _review_ code; not write it. This approach ensures quality as well as providing a feedback mechanism for implementation improvements. It’s very hard to anticipate all problems up front. With agile, the architect needs to follow the entire project so as to resolve issues at the last possible moment–when the most is known about a particular issue. I don’t want an architect coding because it’s not what they do best. I want my architect engaged in design problems and resolving the toughest issues.

  7. You are spot on. Programming is by nature recursive. Big things are made up of lots of little things. “Architecture” is simply programming with broad strokes. And programming is something that must be practiced. Constantly. The devil is in the details, and like a good film director, a software architect must be involved in the details.

  8. I completely agree that architects must be part of the development process.
    I, personally, have been working on systems, large and small for over 30 yrs in both a design capacity (architect) and a developer capacity. Over those years I have come to recognize one undeniable fact, an application (or software package regardless of focus) must have the direct input of the person who designed it.
    If that direct input from the designer/architect is not there then there is absolutely no way that the development team can actually implement anything according to what the architect set up at the design phase or within the time-frames that said design must be implemented. The designer/architect, starts with a vision.
    That vision, through the implementation of various architecting/designing tools, is what drives the development of the application/software package. The codeing itself must be in compliance with the original design/architecture.

  9. It is a big ask for someone to be a quality developer and to have the breadth of knowledge required for quality architecture. There are only so many hours in the day. I suspect the assertion that an architect should code reveals a belief that development does not require full-time, or at least significant attention. This is not my experience.
    A development lead/pure architect pair can work very well together (the last word is carefully chosen).

  10. Architecture, like war plans, do not last longer than the first minute of the battle: the architect must be in the front line, coding, spiking, re-architecturing… At least, that is the way I do 😉

  11. If architects are not coding, they are not keeping their possibility jar full.
    Ok, so they don’t code everything. They need to keep their hand in, or they’ll miss the big changes that happen daily in the industry.
    Architects should keep the project moving forward. If coding interferes with that, an assistant can do project management details while the architect is head-down retooling skills.
    The vision thing needs constant refreshment.
    Nice discussion … it’s a debate that’s at least 50 years old.

  12. Architecture is a broad discipline. I categorize architects as tactical and strategic architects. Tactical architects have oversight over a single product (or small product family). These architects must understand the fine details of the product. As a result, tactical architects must be able to write code as they may have to code the most complex logic of the product.
    Strategic architects will define broad business unit or enterprise architecture designs. These people do not need to be expert coders; they need to be experts in technology and technology integration. Sometimes, they may need to write code in order to validate a design, however, it is a waste of these peoples’ skill sets to assign them as coders.

  13. This is a great topic. I am an architect who codes regularly. Coding certainly helps me stay grounded, but I think the answer to the topic depends on the size and complexity of the project.
    I think it comes down to this: Just like a programmer, the architect should be able to master all of his interfaces. Those interfaces may be based on pre-built systems (which may require no programming) or custom developed components. The more that the architect knows about each of the components and how they interface, the better. This point is similar to the fact that a programmer does not have to know BIOS, hardware signalling and crimping cables, but it helps.
    I’ve been programming now for over 20 years and found that the building construction industry is more like the software construction industry than most of us computer-folk realize. Should an architect be required to know tile-laying, beam-welding, foundation laying, not to mention interior decorating? It certainly helps, but is not realist for a large project. Specialists in those area define constraints which the architect accomodates. Large construction projects like the World Trade Center has a “master plan”, which is the layout that multiple buildings may go into. Each of those buildings have architects and then design falls within the framework that the architect lays out. On the opposite scale, when adding onto one’s deck, one would expect that the person who lays out (architects) the deck would know how to build that deck.
    A key point on this subject is the deliniation of architecture versus design. Not being wary of that deliniation is a great way to get in trouble. “Design” in the over context should refer to the detail that is applied within the architecture.

  14. I agree, Architects must code. Besides getting feedback which is important, how does one know what they are telling others will work? There is only so much knowledge you gain from books, the web and conferences — at some point you must be able to take concept and make it into practice. The architect is the chief keeper of the vision — how does one give birth and life to the vision or direct other to do so if the architect has no clue himself?
    The powerpoint architects are the architects everyone hates because they don’t see their idea through, they don’t get involved in the everyday pain nor are they close to the pain that they sometimes inflict. During the dot bomb era I worked at a company where the architect developed a large Java based architecture. Problem was the architect 1) didn’t know Java 2) didn’t undestand that his coding staff didn’t know Java and 3) was not close enough to project to know that the ship was sinking. 14 million later the project was cancelled
    The first response talks about project reviews or retrospectives — these are all things that should be done but if the architect is only there for these reviews, why bother putting him on the team at all because a review is not enough to tell the whole story. At that point he is johnny-come-lately and has no influence in the outcome — its too late to correct the mistake because the software has to get out the door. This is most especially true of companies where a high level of business domain is required as well as technical knowledge. Often, the technology means little without the domain knowledge.
    This September it will be my 20th year in the software business and in that time the people I have been fortunate to work with who were the best “architects” before the term was cool to use, were the ones who kept the grand vision, who were able to sell the vision and who rolled up their sleeves to cut code when the time was necessary or when a critical part of the whole architecture was involved.
    Its not easy being an architect and the skill set you must have is very diverse — besides great vision, great communication skills, great knowledge of the business domain he must never forget how to cut code otherwise his designs will just be pretty pictures without substance. I have seen over and over again in my work when I have put forth a design that a developer has come back and said “it can’t be done” only to sit down to prove that it can be done — then show them via code how. The side-line/powerpoint architects I have seen often back down and redesign or leave the development team to make work arounds that are often invalid changes that jeopordize the whole architecture. The architect must first and foremost be the most senior developer first and everything else a very, very close second.

  15. I have developed and designed software systems for over 20 years now. I have worked on projects ranging from single-person, 3 month quickies to 4-year, 100 people monsters. There are many things that contribute to a project’s success or failure, too many to go into here (many books have been written on this topic).
    Fred Brooks wrote in “The Mythical Man-Month” that a hugely important factor in the success of a project is its architectural integrity. This is true for any size of project. Architectural integrity is usually achieved by having one chief architect that sees the project through from start to finish, who is disciplined and able to communicate and enforce architectural decisions. The best way to enforce architectural decisions is for the architect to personally (or as part of a small, highly-skilled team of which he or she is the leader) write the code for the architecturally significant infrastructure of the project. My sad experience has been that it is not good enough to entrust the critical layers and components to the average – or even above-average – programmer. The lowest layers of a project, especially a large one, are like the foundations of a skyscraper. Any weakness in the foundation will cause ultimate collapse.
    In addition to this, the architectural decisions that must be made to provide consistency (logging? error handling? exception strategy? test framework? configuration management strategy? layers? enterprise systems management? recovery? and much more) are best made by the architect writing and testing at least the stub interfaces to these components.
    It’s unreasonable to expect that one person can write everything that’s important in a large project. However, one person, or a *highly-skilled*, small team of experts, can certainly lay down the critical elements.
    So should architects code? Most definitely. I have *never* seen a design, even if thoroughly peer-reviewed and QA’ed half to death, that was not modified due to unforeseen situations, or just looked good on paper and didn’t work well in code.
    From what I have seen, the way things are in many corporations right now, not much value is being placed on quality, so perhaps this question is moot anyway? I fear that we are seeing the advent of the disposable project, which is slammed together by brute force, made to stagger along for a couple of years (by brute force again), and then thrown away to be rewritten from scratch (or partially salvaged, like spares in a junkyard, and used as the basis for the next throwaway system). Sorry if this sounds pessimistic, but this is what I am seeing happen.

  16. I would disagree almost completely. Do I think and architect should have familiarity with the tools? Yes. Should the be able to prototype? Yes. Should they be in the trenches? No. Good architecture for software, UI, databases is not a technical skill, it is a listening skill. It comes from the ability to listen to what needs to be done, evaluate the options (this is where you should know the tools and know how to use them or how they are used – but not necessarily do all the coding) and then put in place the most appropriate solution. Being an architect requires the ability to communicate and present, the capacity to sell both upstream and down what the solution should be, then framing it so it can be built. It usually requires the ability to marshal the forces, plan out the implementation, then ride the project (making changes as needed based on feedback from the trenches) to a successful conclusion. But, that’s just my opinion. 🙂

  17. I’m an architect by profession both in engineering building roads and bridges, and an IT architect designing and building major systems; in the past for aeronautics (space) and government programs. I learnt programming long time ago and I know the intricacies of taking requirements to reflect business reality to 100%. Whether I’ve used mathematical calculations to design a bridge for loads, suspension, elaticity, etc. or utilize a super computer to calculate a trajectory to the moon, etc., I must have the knowledge of the subject matter, the skill to read code, the capacity to understad logic and apply logic, know current technology or device new technology (in my case)but I have never been expected to code; not that I don’t know but who is going to oversee the integrity of the project if I’m buried coding a simple routine.
    Many thing go on in a project that the programmer or even the designer can not pay attention to. While I don’t expect to lay concrete or the tile-layer design the house; it is naive to think in those terms. Each of us have a function in the IT machine. I remember during the early days of the card-sorter machines that we were told that it would spell disaster if we crossed hands while sorting these cards; by the same token today, don’t cross one function with another or the integrity of your projects will suffer, risking ridicule, etc.

  18. As an architect who loves to code, I would also love to agree with the premise that architects must code. That we must test our theories out in the real world, absolutely. I use our software engineers for that — including two especially allocated to the architecture realm. I give them a vision and goals, we design together, then they code and give me feedback, and we adjust the design accordingly. That frees me up to spend my time understanding the big picture, watching for new tools and methods, communicating, coaching, and moving the whole architecture initiative along. As soon as I let myself get pulled back into coding, the initiative bogs down.

  19. Yes, architects must code, review code, write and review test plans, and in general follow up. The “throw it over the wall” metaphor for any software development effort is so 1980s, I’d think by now everybody would have gotten that.
    That’s a good question. We love to draw links between the software construction industry and others, including building trades (that’s why we call them Architects, rights?) and automobiles. The assumption that real Architects don’t have to understand how the buildings they design are physically built is wildly wrong. The architects are involved with every phase of construction, from site selection through the ribbon-cutting ceremony, and they do know the details of how their buildings are constructed.
    In the software world, the only way an “Architect” can do this is to be involved in the ongoing process. No set of blueprints survives the building unchanged, and so it goes with software also. The Architect has to remain involved with the ongoing development so he can both adapt the architecture as needed, and can help the developers express the architecture in code. The details of how he remains involved are relatively unimportant, but the involvement is not.

  20. I had the opportunity to work with a snooty Architect. Basically, he thought we were idiots, always referenced his book, always give you his book to read if you had a question, always name dropped C++ greats like Stroustropp, and wasted 6 million on Oracle software. As far as we know, he never coded and only lasted a year in every job.

  21. If we talk in terms of management then planning and controlling go hand in hand. An architect is planning something, he has to get the feedback to ensure that what has been precieved, is implemented. It may not be necessary for an architect to code but he must have coded some time in past.

  22. I think we are missing some critical elements of the design and development process all wrapped up in current circumstances:
    I was a Senior engineer scientist for a major computer manufacturer. I am not a project manager with PMP certification. With 20 years experience in the industry.
    1) “Power Point” architects. This is not a definition of an architecture. We need to go back to some basic level communication artifacts to communicate to developers what must really be implemented. We seem to have lost some basic data flow techniques and capabilities to perform data flow and interface analysis. I would question if this is not the root cause of failures on a “throw it over the wall” circumstances.
    2) Most reasonable development lifecycles involve an iterative development cycle. On each iteration you should learn new information, refine your deliverables and possibly impact your design. It would seem reasonable to have the architects involved in this process.
    3) Why do you have “Architects”? They are extremely strong engineer folks who have shown knowledge of the big picture as well as the ability to implement. The loss of this experience is detrimental. Therefore, I personally believe two items in this area:
    A) Architects should participate in the design and code reviews. This keeps them in the loop of the design and the actual implementation while leveraging their past experiences for other engineers.
    B) You move an individual to a strategic position to leverage future project activities. “Pave the way for the rest of the team”. They have proven track record you wish to leverage on the next project. If they are focused on the tactical execution of the current project, then you have not “initiated” the next release for the development team. You need to apply knowledge and people in the best role for the business and in the end the team.
    4) An overriding factor to my team, the architects (I have 3) must know the implementation but must also be looking to the future – next project, new technologies, next set of requirements on the product. They must look to the future with a STRONG understanding of the product implementation. In the past I had Architects (whom I did respect) but they had lost knowledge of the real implementation….they became less respected by the engineers. This was not a beneficial situation and in the end, self-destructive.
    Therefore, I think the summary is:
    * the architectural artifacts must be such that it leads to clear project design (JUST Power Point is not the answer)
    * the architects must understand and absorb the implementation but can not be distracted from solving my next large problem.
    * the architects must be engaged/respected by the engineers and a member of the team.
    It is not an easy problem and a fine line to walk.

  23. The coder is the architect. (The code is the design.) The compiler is the construction company.

  24. I think the old adage applies here. Some know theory inside and out, regardless of the discipline, but if you cannot execute, or understand the execution of the theory, what assistance can you offer? So many times I have seen “hands off” technologists sink into the pit of old experience and up to date study, make recommendations that at execution time are not the best of solution, that I agree, the architect must to some degree, “code”

  25. It all depends, isn’t it? If the architect is a good coder, without question, he/she would like to code. If the architect likes to code, and does not code well, he/she should just code prototype, at most. If an architect does not like coding, and is bad in coding, you can be sure that the final design will have lots of flaw, unless he/she has a good implementation team and has good working relationship.

  26. It seems we are continuing to ÂlegitimatizeÂ software development by borrowing from engineering nomenclature. Now we have Âarchitects, engineers, builders, etc.Â. If we follow that line of reasoning, no, architects should not code any more than I would expect to see a real architect hanging sheet rock, and installing wiring or plumbing in my house! With 30 years experience in I.T., I can confidently say IÂve not found an ÂarchitectÂ who would want to code, let alone, who I would let code. Conversely, a coder or developer who became an architect makes a lot of sense because they would have a more in-depth understanding of the logical processes required to meet design goals. In our current environment, architects are configuring operating environments, networks or the physical entities in which and by which the applications will be created. This logical and physical separation of tasks provides a secure environment for development and operations.

  27. Architect versus Software Engineer
    (when you confuse the roles you get arguements like this that are really about I code so I am smarter than you even though you are the ‘architect’)
    The architect must understand a lot more than coding to have something that meets customer needs. The architect must decide do we code it, buy or what? If we code it what language makes sense? How many servers? Network issues? Databases issues, Resourcing, etc.
    Once the decision is made you need a lead developer better called software engineer who can code well but says we’ll do mvc, use these classes, re-use this ,etc. To have the same person be the Architect and Engineer probably doesn’t make sense unless the company is so small you have to(doesn’t work that well but you have to).
    The Engineer likes to code, sweat algorithms and doesn’t like to figure out the best technology agostically, decide what users want etc. Well they like to tiddle with code and do it Right!
    The architect is more big picture in that this business problem needs to be solved! and I understand the technology choices well enough to diagram it, convince the business and then make it happen. They need to be part of project teams to refine, understand places they were wrong but they don’t need to be writing “hello world” and believe me the Software Engineer who lives for code doesn’t want them to.

  28. I have no objection to “architects must write code” other than I thought you stopped short. I used to say, the architect must attend the first real implementation when I worked in the telecom space.
    Basically, it’s the “build the right thing” principle. You must see the product in use to know if you built the right thing. It doesn’t matter if you “build it right” but you did not deliver the “right thing”.

  29. As a Senior Project Manager I think it depends on the project and what is gettig coded. I beleive that architects obvioulsy participate in the requirements and design process in order to mitigate the risk of not meeting all requirements. However, at this point in general they should not code for meeting the requirements of the project. They may review code as part of a review process and make suggestions for risk and maintenance purposes.
    That said; architects may code for testing data or run programmers code when they are not readily available for two reasons. One, testing of the code should; one should not be offended when you get an extra hand for risk mitigation. It’s prior to production and usually out of site of your customer. Two, there are times when a programmer is not available, for whatever reason, and timelines need to be kept. For whatever that reason be there was short sightedness on someone’s part during budget and estimating. KEEP THE PROJECT ON SCHEDULE. Don’t get your “short’s all balled up” for getting and extra-hand when a programmer is not availble when there was already a commitment.

  30. I think Architects should have coded a great deal in the not too distant past. By the time they’re trusted to be architects, they should have had a considerable amount of experience building software systems (preferably on a variety of platforms in multiple industries).
    An architect may also be expected to mock up a prototype or otherwise provide a meaningful proof of concept. They should be expected to prove that their designs will scale, provide a desirable level of built-in housekeeping or auditing, perform well in a real-world setting, and be highly maintainable.
    Furthermore, an architect *must never* use “architect” as a verb. It’s a noun.

Leave a Reply
