One Simple Way To Spot Bad Architects
This is a rejoinder to Frank’s article on the same topic. He discusses 13 scenarios. I would like to point to one simple way to spot a bad architect and also how you can spot a good architect.
A bad architect will inevitably show lack of practical knowledge and use specifications and authorities to justify his statement. They are swayed by fads and lacking a grounding on reality will tend to adopt and force anything new and shiny on the poor developers. They are also the over-engineering types. The tendency to over-complicate design is a sure-fire sign of poor architects. It is easy to spot them. Jot down the points above and go to your next meeting. You will know how good your architect is.
A real architect will have a strong grounding on reality. He knows when to use any technology and when not to. He will justify with solid understandable logic when questioned and will not rely upon highfalutin words and specifications. A good architect will also choose the simplest solution that meets the requirements.
PS. I always had this nagging suspicion that UML thumping architects (this who generate reams of UML documents and almost nothing else) are most often than not bad architects. Recently I was trying to use a JSP Table component from a project which repeatedly touted its clean design and UML diagram but didn’t even have a 5 minute user guide. After honest effort to decipher the nearly non-existent documentation and doc-less javadocs I gave up and chose Ext Grid component instead. Have you seen any correlation between UML thumpers and bad architects?
Filed under Enterprise Software, Headline News, How To, Java Software, PHP, Programming, Ruby, Software Outsourcing | 
| 
RSS 2.0 |
Trackback this Article
| 
Email this Article
You may also like to read |
Add to Technorati Favorites
July 3rd, 2007 at 2:10 am
Uhh… so the one simple way is… what…. UML use?
Actually, that sounds about right to me.
July 4th, 2007 at 3:06 pm
UML is brain damaged.
For starters, UML is specified in… UML. This means that UML means… whatever UML means, because it is specified in itself. People who know algebra or geometry will be laughing.
There are no successful projects delivered using UML. You can laugh, but UML is an energy drain, since there is no way you can prove a design with UML is right nor wrong, therefore it is a waste, because it is open to interpretation. Most successful projects ignore UML completely and avoid it like the plague. This is not coincidence, but a serious decision to make.
Java was not designed using UML, nor it’s class library. Still there are no compelling UML design for the Java class library and it has been around for at least 10 years. How come? Nobody can do it or it is found that it wouldn’t be useful?
I have another explanation: Wouldn’t it be possible that real engineers know that UML is a scam?
Have you ever seen diagram of design patterns (Java best practices)? There are at least 24 design patterns with name and example code, but all UML diagrams made for them look the same. Would you use UML to document the design patterns you used? I bet you wouldn’t, because it would be considered a waste, but then how can you explain your design if you can’t draw them?
UML class diagrams do not show polymorphism in your programs and polymorphism is the key to object orientation. Why is that so?
UML sequence diagrams do not show polymorphism and break encapsulation. Encapsulation and polymorphism are at the center of object orientation. Why is UML marketed as an object oriented tool if it works against object orientation?
UML use cases are simply escenario-oriented documents, specifying “steps” for the user to use the system, while we know that modern user interfaces (since 1984) are event-oriented, and therefore you can’t force the user into any steps since the user selects the steps he wants to do.
Furthermore, Rational was the company behind UML. Where is Rational now? Why their people lost so much momentum?
Finally, Rational Rose was the key product marketed by Rational, but the product was obviously bloated (too big), underperforming (too slow), unusable (hard to use) and buggy (a diagram that extended beyond a page was usually the one you could not save).
The fact that most UML architects can’t code is a sign that shows that they don’t know what they are talking about, yet they have very strong opinions backed by companies that create UML design tools, a whole ecosystem. Architects should be able to code and give recomendations on how to code, pointing to design patterns when necesary. Doing code reviews and writing code conventions, for example, should be at least 20% of the time spent every day by any serious Java architect.
July 5th, 2007 at 12:54 am
The purpose of UML was to communicate architectural and design ideas to developers. Unfortunately the means to communicate (UML) is often more complicated than the ideas themselves and also often incomplete.
We need a better and simpler alternative.
July 5th, 2007 at 9:35 am
There is an alternative. It is called Functional Dependencies.
Functional dependencies are the basis of database modelling, but also can be applied to system design.
For example, if you can find out that the color of the website will depend on the user logged in, then your write:
user ->> website color
If later you realize that the website color depends also on the time of the day:
(user, time) ->> website color
You can replace all those dependencies (they are just text).
Imagine now that you have several thousand dependencies expressed that way, and that you have a parser for your dependencies. Voila! Your system is finished!
July 10th, 2007 at 6:55 pm
Are you assuming that a non-coding architect is a bad architect? If so, I disagree with you. I have seen many non-coding architects who have been beneficial, if not vital, to the success of a project. A coding architect can result in a variety of issues for a project. The example I have seen most often are the coding architects that do not trust other “lower” developers and try to code too much of the application. This results in a lack of attention to key concerns and issues, as well as project failure.
I have found those who paint non-coding architects as “bad architects” may have had one negative experience, and afterwards they generalize all non-coding architects as bad. Or, in some cases, the person is jealous of the architects’ skills, believing that coders are the more important part to a project.
The key is not to identify a coding or non-coding architect, but to be able to identify whether the architect can properly discover and address key concerns for a project and then resolve them. In the end, it should not matter if the architect codes or does not code, so long as the concerns have been properly addressed. If a reference implementation needs to be developed, I am more than happy to see an architect delegate it to someone else.
Rational is still around ~~shiver~~ as part of IBM’s Rational product line. Very buggy and very costly IMHO (I opened three bug requests within one week of usage). Not to mention RAD is a beast. As far as UML goes, I will still take a strong set of use cases, an object model and sequence diagrams for complex functions in the system. It works; it is proven across the fifty or so systems I have architected, developed and/or managed. Outside of those three, I can get away with my own functional models outside of UML.