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:
- Architect: “You can’t do it that way, because it breaks the code guidelines”
- Architect: “You can’t do it that way, because it won’t be safe when there are several users”
- Architect: “Have you thought of how it will work with several users?”
- 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.
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?
Good observations, qnaguru. I find that the more I know, the less I use. :-)
“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… Read more »
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… Read more »
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… Read more »
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… Read more »
“Oracle SOA Server”……2yrs implementing it
waste of money/time
bloated sh!t
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.)
DROOLS and JUNIT are among the top useless technologies…
Value you get out of these useless bloat is zero.. or rather negative.