About Johannes Brodwall

Johannes is the chief scientist of the software offshore company Exilesoft. He's got close to 15 years programming Java, C# and a long time ago other languages as well. He believes that programming is about more than just writing the code, but that too many people lose touch with the coding as well. He has been organizing software development activities in Oslo for many years. In addition, he often speaks at conferences all over Europe.

Humble architects

Humility is not a very common trait with software architects. After having worked with a few awful architects and recently with a very pleasant one, I’ve compiled a few of my experiences in the way every architect loves: As a set of rules.

Rule 0: Don’t assume stupidity

It seems like some architects assume that developers, if left to their own devices, would behave like monkeys. In my experience, this is very rarely the case. The only situations where I’ve seen developers do something stupid is when silently protesting against an architect. If you follow this rule, the rest are details.

Rule 1: You may be wrong

When reviewing someone’s design idea, I prefer to try and ask questions that are honestly open. Maybe I think the developer have overlooked a critical fact, for example concurrency. There are a few different approaches to the situation:

  1. Architect: “You can’t do it that way, because it breaks the code guidelines”
  2. Architect: “You can’t do it that way, because it won’t be safe when there are several users”
  3. Architect: “Have you thought of how it will work with several users?”
  4. Architect: “How does your solution address the situation of several users?”

Dear architect: Please rate these approaches from the one least to the one most likely to get a best possible system. (Tip: This is an easy task, even though many architects fail it routinely)

Rule 2: Be careful with technology

Every technology comes with a cost. Many technologies come with an infinitesimal benefit.

Here’s a list of technologies that I’ve experienced as having consistently higher cost than benefits, and thus will never use (if you don’t know them, don’t worry. The point is the number): JavaServer Pages, Java Server Faces, JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMS (all implementations), JBoss.

Here’s a list of technologies that I happily use: JUnit, Jetty, Joda-time, Java Standard Edition.

Here’s a humble exchange that you may want to try and copy:

  • Architect: You should use technology X
  • Me: I’ve looked at technology X, and I don’t see how it will help me solve the business problem
  • Architect: What do you mean?
  • Me: Well, this is what we need to do: ….. And this is what technology X assumes: …. I don’t see how they match.
  • Architect: So what do you suggest using instead?
  • Me: Um… I think we can solve this with plain Java. As a matter of fact, I made a pretty good proof-of-concept yesterday evening.
  • Awesome architect: Cool. Let’s use it.

Rule 3: Consistency isn’t as important as you think

If I’d have a penny for every time I’d hear this….

  • Architect: “Yes, I know this way may seem clumsy, but you have to do it. You see, if you don’t, the system becomes inconsistent and impossible to maintain”

Granted, I don’t often work with maintenance, but I know that when I deal with any system, the most difficult part is understanding the business logic for that system. Whether system X (which has one set of business logic) and system Y (which has another) are consistent is very low on the list of things that make me lose sleep.

The fact that system X is horribly complex because it has a dozen layer to be consistent with system Y – now this is something that does make me want to pull out my hair. Different contexts have different trade-offs.

Oh, yes: Remember Rule 0? Assume that the developers in a given context are trying to create a good solution for that context.

Oh, yes, another thing: I’ve never seen something that was incomprehensibly complex in the small become maintainable just because we grew to become big.

Oh, yes, yet another thing: If a programmer really runs screaming away from the code because some of it had one style of curly braces and some had curly braces in another style, I’m going to lose all faith in humanity.

Rule 4: Bottom-up consistency beats top-down consistency

There is one way I’ve been able to create more consistency inside a system:

  • Create a reference application with an architecture that is easier to follow than to break. If you do this well, the developers will shake their head at the very idea of deviating from the architecture. Unless they really need to. In which case it’s okay.
  • Foster a culture of cross-pollination: Developers who see each other’s code have more consistent code than developers who just see their own code. Pair programming, code reviews and tech sharing sessions all foster cross-pollination.

Rule 5: Tactical reuse in across systems is suboptimization

Reuse creates coupling. If system X and system Y reuse some functionality and system X needs that functionality to be modified, this will affect system Y. At the very least, the team working on system X must decide to make a private fork of the reused functionality, which means that it’s no longer really reused. At worst, system Y will get a bug because of a change in the reused functionality.

When you reuse across systems, what you reuse should either be stable (say: the Java SE platform, or something so stable that you definitely didn’t make it yourself) or strategic. By strategic reuse, I mean services that integrate information and not just duplicate functionality.

In other words: Reuse should either be use or integration. Duplication is your friend.

Rule 6: Separate between rules and dogma

There are three reasons to have a rule in any coding standard:

  • Unsafe: The code has a bug that will manifest under some (non-theoretical) circumstance
  • Incomprehensible: “I” don’t understand what’s going on
  • Heresy: The code is written in a style some person doesn’t like

Pop quiz: If you have a rule that says “all fields must have a JavaDoc comment”, is that a safety issue, a comprehensibility issue or a heresy issue? What if the standard uses this example:

/**
 *  Contains the name value of the object
 */
private String name;

What about the rule that says “no newline before an opening curly brace”? What about the rule: “the style used for curly braces should be consistent”? Is it addressing Unsafe code, Incomprehensible code or Heresy?

We should be more concerned with writing appropriate code for the situation and less concerned with appeasing the Gods of Consistency.

Rule Omega: Be humble

In the years I’ve worked with software development, I’ve seen more harm done by software architects than help. As a professional role, I think we’d save money if we got rid of them (us). Even if we still paid their salaries.

When you’re in a profession that causes more harm than they prevent, you have two options: You can try and improve, or you can pray that nobody notices.
 

Reference: Humble architects from our JCG partner Johannes Brodwall at the Thinking Inside a Bigger Box blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

8 Responses to "Humble architects"

  1. qnaguru says:

    LoL :)

    I like the list of mostly useless technologies!

    But people use it becz:
    -They do not understand IT
    – Or worse simply to update their profiles, not necessarily to solve problems.

    And Higher Mgmt, ppl who r decision makers r mostly ignorant and love buzzwords.

    SIMPLICITY anyone?

  2. “Here’s a list of technologies that I’ve experienced as having consistently higher cost than benefits … JavaServer Pages, Java Server Faces, JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMS (all implementations), JBoss.”

    I’m going to disagree with you on Spring, Spring is probably the best documented framework out there and gives you plenty of puzzle pieces to take care of a lot of stuff you have to do over and over again and I have yet to run into the “solves 90% of my problems easily, is a nightmare for the other 10% of scenarios”. Spring Integration is especially useful when doing a lot of integration work into legacy systems.
    If you’re not using JSP, what else are you using? Spring MVC?

    You forgot to add Struts to that list, Struts and JSF are both pukeworthy.

    GWT I fully agree with, it blows up a simple application into 10 – 50 times the code it needs to be.
    Hibernate gets the job done, I’d take it anytime over EJBs but would prefer clean JPA.

    jBoss BPM is really horrible to work with, Camunda is just so much easier.

    Maybe do a technical post where you discuss the problems you’ve had with some / all of these mentioned tech.
    I’ve worked on projects where the team developed their own homegrown framework, and personally it’s that much worse to work on than simply using an existing framework that has proper documentation and has been around for a substantial period of time.

    • Thanks for the comment, Jan. As it so happens, I did write a follow up on Spring, since there were many comments similar to your own: http://www.javacodegeeks.com/2013/12/why-i-stopped-using-spring.html :-)

      In short, I find that Spring increases the amount of magic (and/or XML) in my code without really reducing the amount of code I need to write.

      These days for HTML, I mostly use static HTML and JavaScript. If forced to do HTML on the server side, I probably would use static HTML and server side Java tree manipulation (I had to write my own library for this, as those that exist are very clunky). I am not thrilled about this option, because it’s only a skip and a jump away from “we wrote our own framework”. Words that make me cringe as well.

      • If by Spring, you mean Spring IoC, I also dislike all that magic happening in my code, so in that sense I agree with you (I try and keep the XML and depdendency injection to the bare minimum).
        When I’m referring to Spring, I’m referring to the whole platform, in other words Spring Core + Spring Web Services + Spring MVC + Spring AMQP + Spring Integration + Spring Social + Spring Batch + etc etc etc (as an alternative to pure Java EE – not to start a JavaEE VS Spring debate, but the Spring ecosystem is very convenient to use, especially if everyone in the team already knows Spring).

        If you’re using pure HTML and JavaScript, how do you manage the URLs? (Servlet(s)?, directly on the load balancer?)
        I recently spent 16 months on a project, long story short, the frontend started with one servlet mapping / to a Servlet class and code mapping urls to static html files, ended up turning into a full-blown-REST-framework that does 90%+ of what Spring MVC offered right out of the box. So that begs the question, should I have just used a RESTful framework right from the start …

        Architects (myself included) often wants to write stuff from scratch so they have full control over the stack whereas sacrificing a little bit of that urge to be in full control often means anyone can pick up where you left of. Furthermore, let’s say you use Play or Lift, then doing things have a standard way of doing it that is well documented whereas in your own framework, let’s say you’re away for 2 – 3 weeks, a team of developers can wreak havoc in that system because they don’t see the bigger picture that you saw when you designed it.

        Thanks for your insights!

        • Yeah, it’s IoC that I dislike. There are some remarkably good spring libraries. However, I fear that rookies on the team will start sneaking in IoC stuff if we have other libs. Perhaps not the best reason to avoid…

          I find that URLs don’t become that much of a problem if I’m structured. I generally only use URLs starting with “/”, which is less of a restriction than I expected. For cross site stuff, I have been found to build links with JavaScript.

          I’ve felt a little bit like the situation you describe at times. “Building our own framework” feels icky. “Framework is not needed” feels nice.

  3. Stephen McConnell says:

    It is fun to work with good Architects. Especially those that work with you using the technique in Rule 1, case 4. They are interested in teaching and mentoring and ALWAYS assume they can learn something from each and every developer.

    I have worked with Architects that assume you are an idiot and love to use new technology for new technology’s sake. They are the ones that diss Java or don’t like Python because it forces you to indent but want you to use a brand new NoSql database still in Alpha…. (Been there seen that.)

Leave a Reply


1 + = nine



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close