One Simple Way To Spot Bad Architects

Architects are not just the designer, but they have this responsibility that it can really be done in reality and with good proof that it is going to work if the design is not usual. Thank you for sharing this posting.

I find the UML to be a very useful way of keeping track of my own designs. I am a “coding architect” (and I cut a lot of the code we write myself), but I’m also very visually-oriented (my 2nd degree is in Fine Arts). I find ULM diagrams to be a great way to clarify class relationships in my head. Admittedly, I only use static structure diagrams. We tried using activity and collaboration diagrams, but they were just a waste of time since we were also writing good requirements documents.

As to the point about UML being useless because it’s defined in UML… you wouldn’t say the same of an XML schema, would you?

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.

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!

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.

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.

Uhh… so the one simple way is… what…. UML use?

Actually, that sounds about right to me.