Brodwall is a programmer, solution architect, user group and conference organizer, conference speaker and evangelist. Johannes has worked hard to apply agile principles to large software projects, but what he is really interested in is sharing more interesting programming lessons with programmers around the world. Johannes currently works for Exilesoft as chief Scientist. Recently, Johannes wrote an article titled “Humble Architect”, which discussed the principles that architects should follow, and it got a lot of buzz from the programmer community.

Humility is not a very common trait for software architects. I’ve worked with some horrible architects (who often scold you: you’re Low because you don’t use XXX technology) and recently with a great architect. With that in mind, I put together my past experiences in a ruleset that I can share and discuss in a way that every architect likes

Rule 0: Don’t be foolish and make assumptions

It seems that some architects feel that when developers are left to their own devices, they are as chaotic as monkeys. In my experience, this is actually very rare. There’s only one situation where developers do stupid things, and that’s when they silently resist the architect. If this principle is followed, everything else will be a matter of detail.

Rule # 1: You may be wrong

When reviewing someone’s design ideas, I prefer to ask questions in an open and honest way. Maybe I think developers are missing a key fact, like concurrency. There are several different ways to do this:

Architect: You can’t do that because it breaks the coding specification. Architect: You can’t do that because it’s not secure when you have several users at the same time. Architect: Have you thought about how it handles several users? Architect: How does your proposed solution handle the situation of several users? Dear Architects: Please rate these approaches, from worst to best (hint: this is a simple task, but many architects still don’t get it right).

Rule 2: Be cautious about technology

Every technology comes at a cost, and many offer very limited benefits. Here’s a list of techniques I’ve used that cost far more than the benefits (if you don’t know, it’s all about quantity) : JavaServer Pages, JavaServer Faces, JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMS (all implementations) and JBoss. Here’s a list of technologies I like to use: JUnit, Jetty, Joda-Time, and Java Standard edition.

Check out the conversation below:

Architect: You should use technology X. Me: I’ve seen technology X, but I’m not sure how to use it to solve business problems. Architect: What do you mean? Me: It’s something we need to do… This is a problem that technology X can solve… I don’t know how they match up. Architect: What do you suggest? Me: I think we can solve this problem with plain Java. In fact, I did a pretty good proof of concept last night. Architect: That’s cool. Let’s do that.

Rule 3: Consistency is not as important as you think

I hear it all the time:

Architect: Yes, I know it seems awkward, but you have to do it. As you can see, if you don’t do this, the system becomes inconsistent and difficult to maintain. Ok, I don’t do much maintenance, but I know that the hardest part of working with any system is understanding the business logic of the system. It doesn’t matter that system X (which has its own set of business logic) is consistent with system Y (which has another set of business logic). If the reason system X is so complicated is because it adds so many layers in order to be consistent with System Y, then I’m really going crazy. Different contexts have different trade-offs. Remember rule 0, a developer develops in a given context, then he creates a good solution for that context. Also, I’ve never seen a small system that was so complex that it became more maintainable as it got bigger. If the only reason programmers are upset is because some code uses curly braces in one style and some code uses braces in another, then I would be devastated.

Rule 4: Bottom-up consistency is better than top-down consistency

I have a way to achieve more consistency in the system:

Create a reference application and use an easy-to-follow architecture. If done well, developers will always remember not to deviate from the architecture. Unless they don’t want to, it’s ok. Foster a culture of mutual support. Developers who can see each other’s code are more consistent than those who can only see their own code. Pair programming, code reviews, and technology sharing lectures all help foster this culture.

Rule 5: Reuse across systems is secondary optimization

Reuse leads to coupling. If system X reuses some functionality with system Y, and system X needs to modify some functionality, this will affect system Y. At a minimum, the System X development team must create a private branch of the reused functionality, which means that functionality is not actually reused anymore. Even worse, a change in the functionality being reused can cause bugs in system Y. When you reuse across systems, what you reuse should be either stable (for example, the Java SE platform, or a very stable feature) or strategic. By policy reuse, I mean services that integrate information and not just replication capabilities. In other words, reuse is either use or integration. Repetition is your friend.

Rule 6: Distinguish between rules and dogma

Any coding standard needs principles for three reasons:

Unsafe: code Bug will only in some cases to emerge To understand: I don’t understand what a heresy: some people do not like some code style If there is one rule says to “all attributes must have JavaDoc comments”, so what do you think this is a security issue, puzzling problems or heresy? Take a look at the following code example:

/ * *

  • Contains the name value of the object */ private String name; If the rule says, “The opening curly brace cannot start on another line,” what about the rule, “the style of the curly brace should be the same?” What kind of problem is that? We should focus more on writing proper code and less on getting distracted by all this damn consistency.

Rule 7: Be humble

In all my years of software development, I’ve seen software architects do things that hurt more than they help. As a professional role, I think it would save a lot of money to remove these architects from the team. If you’re in a career that’s doing your team more harm than good, you have two choices: keep improving yourself or hope that no one notices you.