When I once invited Bertrand Meyer to our location in Munich, he gave an excellent talk on Software Engineering. His most memorable messages were "Bubbles don't crash" and "All you need is code".
With the first message "Bubbles don't crash" Bertrand referred to all those engineers who have turned into Powerpoint or UML freaks. A Powerpoint slide or UML diagram will never crash (if you don't use it as a model for code generation, the MDSD guys might argue). It is surprisingly easy to impress people with simple boxes and lines (sometimes dubbed software architecture). Especially it is rather simple to impress top management which is why the wrong consultants can potentially cause so much damage. Some might respond that high abstraction levels are the only way to understand and build complex systems. That's certainly true. On the other hand, you would not be able to build a ship if you never had any idea about water. The same holds for software systems. It is simply not possible to develop a software system without any idea on top of which runtime environment it is supposed to execute.
Even if you had in-depth knowledge of your software system's runtime environment and built an excellent software architecture, it is NOT a no-brainer to transform a software architecture to a working implementation. That's why Bertrand introduced the "All you need is code" attitude. What helps you the best theory, if you can't turn it into practice? As an architect you need to have implementation skills, either for implementing parts of the system yourself or for assessing the results of other team members. How could you ever build a good bicycle without biking yourself?
The problem arises how to ensure that we as software architects can meet these requirements. "Architect always implements" means that you should also implement in a project, but definitely not on a critical path. By implementing you will earn the respect of developers, while keeping in touch with the implementation at the same time. And you will have to eat your own dog food. Whenever something is not as expected you can detect the problem and help solving it. However, in some projects architects are busy due to communication, design, and organization efforts so that spending time for implementation will be almost impossible. Never say impossible in this context, do not even think it! Even in such scenarios I recommend spending some of your time for code reviews and some of your spare time to get familiar with software technologies being used in your project context. Otherwise you will create kinds of Software Frankensteins: creatures you are not proud of and who tend to live forever unless not eliminated in an early stage.
Architects are not just masters of Microsoft Office and of a bunch of drawing tools they leverage to create design pearls, throw them over the fence to the developers who ought to build a perfect implementation, while the architects enjoy their holidays on a nice Carribean island.
Be pragmatic! I guess, the Pragmatic Programmers book series was created for exactly the same reason; to make us aware of the relevance of practical experience.
Never ever forget: ARCHITECTS ALWAYS IMPLEMENT. There is no exception to this rule.
4 comments:
Hello,
Indeed architects *must* implement.
From my experience this downgrades to the following pattern: Mr. architect X selectively choose what to code, ignoring the technical debt/his own food which he imposes on the others. Mr. X (safely?) assumes that his solution is the best compromise for the current situation, and he codes a rather core/challenging small solution. By restricting the scope, Mr. X eats only the ice cream, by-passing the other meals.
I would suggest a slogan: 'Architect always code on all layers/components' in order to get feedback where all the weak-points (pains) are.
Sure, this basically implies architects shouldn't choose the ice cream but take the full meal :-) Eat your own dog food! I guess, there are two issues here. On one hand, architects should implement to always decide on solid ground. You can't teach dancing when you never have danced yourself intensively. On the other hand, your point is they shouldn't pick the nice parts but should be responsible for a fair share of the implementation work. From my experience this really depends on the project. In a project with several hundred people involved you can't be lead architect and implement. In an agile project setting with five people, maybe there is one lead architect, but al team members involved are in fact developers, architects and testers at the same time.
All architects do NOT have to implement. It depends on what type of architect you are. Do you really mean that an Enterprise Architect for a big company should implement? What should he/she implement?
I didn't say all architects should imlement. It is specifically about software architects
Post a Comment