Comments on: Architects Must Write Code

By: Dan Clamage

Dan Clamage — Wed, 24 May 2006 03:58:37 +0000

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.

By: John

John — Mon, 22 May 2006 23:27:44 +0000

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.

By: Bob Ferguson

Bob Ferguson — Mon, 22 May 2006 20:39:52 +0000

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”.

By: fletch

fletch — Fri, 19 May 2006 21:57:01 +0000

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.

By: Bob Keller

Bob Keller — Wed, 17 May 2006 21:58:06 +0000

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.

By: Jim

Jim — Wed, 17 May 2006 21:35:07 +0000

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.

By: sshea

sshea — Wed, 17 May 2006 18:54:23 +0000

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”

By: fm

fm — Wed, 17 May 2006 17:05:50 +0000

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

By: Stewart Mayott

Stewart Mayott — Wed, 17 May 2006 10:21:47 +0000

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.

By: Naveen Mankotia

Naveen Mankotia — Wed, 17 May 2006 09:11:13 +0000

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.