Top 7 of 97 Things Every Software Architect Should Know

Last week I commented on the 97 Things every programmer should know. I figured I would do the same for the 97 Things Every Software Architect Should Know. Initially I thought there may be some overlap between the 2, but they have done very well to focus each book on the targeted readers. I did however feel that quite a few of this "97 Things" were very similar in the principle they were trying to explain and so I grouped them under the relevant principle.

Before I start I just need to comment on the first chapter of the book:
Don't put your resume ahead of the requirements - Nitin Borwankar

I am not sure how I feel about this one. I understand the point and I do partially agree, but it also doesn't mean that the "latest shiny object in the latest shiny language or the latest shiny paradigm" isn't the best thing for the company or project. The choice of some new technology for a solution is a very difficult one and should not be taken lightly. Staying with what is already known is definitely the safer option and possibly the correct choice for a project or company in the short term, but when does this become something that actually does more harm than good?

Moving along to my top 7 things:

1. Understand The Business Domain - Mark Richards
Us "systems" folk, often experts in our own field don't always spend the time to understand the actual business we are involved in e.g. insurance, finance, marketing. To be a more effective software architect appropriate industry knowledge is as important as staying up to date with tech.


2. Before anything, an architect is a developer - Mike Brown
"If you design it, you should be able to code it."
I am a firm believer in the above statement. Architects sometimes don't have the time or the will to keep their developer skills current and over time let these skills atrophy. This can then lead to grand designs, with ugly implementations with unhappy developers


3. Dealing with Developers
There were a couple topics on interaction with developers, I decided to group them into 1 point:
Find and retain passionate problem solvers - Chad LaVigne
Give developers autonomy - Philip Nelson
Empower developers - Timothy High
An architect may be a developer, but he also needs to lead them, like it or not, architects by default have a leadership role to play when it comes to the developers on their project. Developers left to their own devices will run wild (we always do ;) ). So as with most things in software architecture it's all about balance:

if (Too much control)
developers = unhappy
else if (Too little control)
customers = unhappy

if(developers or customers are unhappy)
result = bad

I believe the relationship between developers and architects is one of the many crucial factors in the success of a project.


4. Performance
There are 2 topics about performance:
It's never too early to think about performance - Rebecca Parsons
Application architecture determines application performance - Randy Stafford
In my current environment where transaction processing times are tightly monitored and contracted with SLAs that have financial implications, performance is always top priority. However in many other teams / projects / companies I have worked in the emphasis on system performance is almost always left to the end, and sometimes no amount of hardware is going to solve the problem.


5. Record your rationale - Timothy High
This is something that I feel is often neglected. Quite recently a project that I had been involved in for a long time hit the spotlight for all the wrong reasons: customer, user and management dissatisfaction. The first thing to be questioned was not the analysis, requirements, testing, management or expectations, but rather the architecture. Documentation discussing all the decisions, options looked at and reason for options taken would have been valuable. When things go fine, no one will even know about the document, but when things turn bad as they sometimes do having justification and documentation for all the major decisions will be a lifesaver.


6. Stand Up! - Udi Dahan
"The easiest way to more than double your effectiveness when communicating ideas is quite simply to stand up."
This is more of a general point rather than one just for architects, anyone attempting to influence people and situations can benefit from this principle.


7. Great software is not built, it is grown - Bill de hora
"The single biggest predictor of software failure is size; on reflection there's almost no benefit to be had from starting with a large system design."
"Have a grand vision, but not a grand design."
It is all too tempting to jump in and design the total solution. By starting with a basic, small, solid system implementation and growing from that base over the life of the project always with a grand vision in mind, you allow the software to evolve rather than just stuck together. Evolution turned out ok for us, no reason it shouldn't be the same for software.
This approach should not be confused with prototyping, there shouldn't be any quality shortcuts taken and it shouldn't be thrown away.


All the contributions for both books are actually available on the O'reilly site:
Programmer
Architect

There are also a number of "things" not included in the books available on the wiki.

//ignore the next bit
Technorati claim:987BEU5BKS8H

Top 9 of 97 Things every programmer should know

I recently finished 97 Things every programmer should know. Well to be completely honest I did skim over a couple of the 97, but all and all this was a very nice compilation of thoughts and topics about software development from very experienced authors. Well worth a read.

A couple of the "97 Things" discussed, stood out more than the others, the following would be the ones I rank as my top 9.

1. The Boy Scout Rule - Robert C. Martin (Uncle Bob)
"You don’t have to make every module perfect before you check it in. You simply have to make it a little bit better than when you checked it out."

To be honest this is not something I have followed throughout my career, and although I certainly try improve code where I can, I never did it per check-in. I do however feel that it is an awesome principle and should be something that is actually part of a code review process. It is all to easy to just say:
"It was like that already"
"that nasty code was there for years, I am not going to touch it."
"It never had any tests"

I work in a corporate environment were applications often last for 4-10 years. If part of the process is always to just make something a little better, everything from deleting unused code to writing a single extra unit test, year after year... it will end up with saving a lot of people a lot of time and money.


2. Beauty Is in Simplicity - Jørn Ølmheim
"The bottom line is that beautiful code is simple code."

Over the years this has become particularly important to me. Earlier in my career, especially when starting somewhere new I would design the crap out of something.
It would be: "Welcome to the school of over-engineering", everything would be abstracted to the nth degree, there would be patterns for the patterns, interfaces on interfaces for the abstractions and a huge amount of code and components catering for every "what if" that ever existed, that only I understood. All of this would lead to very "fancy" code, and me stroking my ego, but at what cost?
Only the minor little one: an utter nightmare to maintain. I have for a while now favored the simplest implementation of almost any solution, even if it is not necessarily the prefect technical implementation. In the world of long living software, maintainability should quite often outweigh other concerns.


3. Step Back and Automate, Automate, Automate - Cay Horstmann
I believe in automating everything possible: builds, deploys, code analysis, unit testing, functional testing, integration testing. None of us actually want to look at that stuff everyday and automation is the only way to get away from that. Can't say automate enough. Automate, Automate, Automate.


4. Continuous Learning - Clint Shank
This is a very important topic, we are in a industry that is constantly growing, changing, shifting and as a programmer you need to be learning and improving yourself wherever you can. It's very easy to get into a comfort zone and just rest on your laurels, I did that for a couple years, and I do regret it now.
Things I am trying to do to keep up and would recommend:
1. Get a Kindle... then buy & read books.
2. Use Google Reader add the popular blogs and website RSS feeds for your specific field as well as a couple outside your field that interest you.
3. Start a blog, by putting my code and thoughts out there, I put in more effort knowing that it's going to visible than if I just wrote the code/article for myself. I also force myself to do 1 - 2 posts a week, ensuring that I must always find new content to learn about.
4. Join an open source community, we generally don't get to do enough "technical" development in our corporate environments.


5. Check Your Code First Before Looking to Blame Others - Allan Kelly
Exactly what it the title says, we all look to put the blame on anything other than our "perfect" code. Everything from the OS to the network guys, the DBAs to the JVM, 3rd party libraries to other teams' interfaces are always blamed first. This often leads to countless hours of wasted effort, or completely avoiding the issue that eventually comes back to bite you in the butt. Most of us can mention moments where we have done this, it's frighteningly common.


6. Hard Work Does Not Pay Off - Olve Maudal
"truth is that by working less, you might achieve more"

"If you are trying to be focused and “productive” for more than 30 hours a week, you
are probably working too hard."

I couldn't agree more with Olve Maudal. A lot of us have been there, we have spent the days, weeks, months at work, but we often don't see the negative sides of what happens when you work 50-70 hours a week. Everything from common logic to motivation and team dynamics go out the window. Even if the short term goals are achieved, quite often the long term repercussions are a lot worse. No one goes back and see's why they have to re-write a system 4 years down the line because the architecture or code is failing. I'd love to know how many of those were because of ludicrous hours and impossible time lines. I can think of at least 2 "re-writes" that I was involved in where you could see it was the result of long hours. People you know to write great code end up hacking solutions at 1am in the morning.
There are times and there always will be, where a couple extra hours are required, just try keep them down to a minimum.


7. Comment Only What the Code Cannot Say - Kevlin Henney
Exactly that... Don't tell another programmer what he can see in the code. Comments stating the business reason or requirement behind a particular complex algorithm is a lot more useful than //loop through the outcomes and add 1.


8. Know Your IDE - Heinz Kabutz
Something a lot of us are guilty of, we spend a couple hours a day in our IDE, learn the shortcuts, learn the features, we probably couldn't begin to calculate the time that would be saved if everyone used their IDE to it's full potential.


9. Learn to Estimate - Giovanni Asproni
I feel this is something that comes with experience, I pride myself on my estimates and over the years I have tried to nurture this "skill". I have a couple points I would like to share on how I get better estimates:
1. Be honest with yourself, make sure you know what you think you know, and openly admit what you don't. This is the quickest way to end up in trouble.
2. Keep track of what you do and how long it, not necessarily for the project manager, but for yourself, see point 1.
3. Don't rely on other peoples perceived skills and timing, see point 1.


Will try get through the rest of 97 Things Every Software Architect Should Know in the next week or so, will be interesting to see how it compares to the programmer one and how much overlaps.

Creating your own custom Spring configuration.

Recently I volunteered myself to do some of the Spring integration for Hazelcast, for one main reason actually.. I had always wondered how to actually do that. It is something you don't get to do often in a corporate working environment. As with most things Spring related it actually turned out to be very simple.

First thing I needed to do was define a schema for the Hazelcast xml config. If you want to add your custom XML configuration into Springs', it will require that you have a schema for the specific XML.

So what is the quickest way to get started on a schema? Altova XML Spy, it generates a basic XSD form a sample XML which takes care of about 40% of the actual work. Then it's all about the details, min / max constraints, enumerations, defaults, attributes and documentation. I believe XSDs should be verbose, so the version below is not 100% complete but it is a good starting point.
I am not going to add the XSD to this post as is quite long and doesn't add much with regards to the actual Spring integration. If interested, it is available here...

On the Spring side you need the following:
1. An implementation of: NamespaceHandlerSupport, this basically tells Spring when it finds "hazelcast" use the "HazelcastBeanDefinitionParser".



2. An implementation of: AbstractSimpleBeanDefinitionParser. This implementation actually processes the XML from the Spring application config. You need to override
getBeanClass and doParse methods, to specify what type of object and how to create it respectively.


3. 2 files in the META-INF
3.1. A spring.handlers file containing the namespace and the NamespaceHandlerSupport implementation (in my case):
http\://www.hazelcast.com/schema/config=com.hazelcast.spring.HazelcastNamespaceHandler

3.2. A spring.schemas file containing the location of the schema:
http\://www.hazelcast.com/schema/config/hazelcast-basic.xsd=hazelcast-basic.xsd

and that is it...

The XML you described in your XSD is now available to be used within your the Spring config.

The example below is a Hazelcast map cache config, which can then be injected where required as ref="config".



The source and tests for this are available in the Hazelcast code project here.

Spring 3: Spring Expression Language - SpEL

I realized that I have covered most of the major functions in the Spring 3 release, but completely overlooked SpEL. Now even though I am a huge Spring fan, all this functionality does actually scare me a little bit. To often have I seen people hang themselves with awesome, innocent looking ropes just like this one. Soon there will be some project that needs to be "dynamic" and some person/consultant/architect/developer will have this amazing idea and place code somewhere they can edit it externally. Then this SpEL can read this and "dynamically do stuff"...
(I am pretty sure that I have been that "person" somewhere in my career, it all feels horribly familiar.)
And all of that only comes at the price of some poor developers' sanity trying to maintain it. To be fair, this view is purely based on personal experiences and maybe slightly unjustified, but I have seen my share of good ideas gone bad in my time and it feels like SpEL is wide open for misuse.

Putting my concerns aside and refocusing on: it's something new , it's shiny and Spring-made so I obviously can't resist trying it out.
First I go digging for information to answer: "What is SpEL, Spring Expression Language?"
A quick summary of what I find:
It is an expression language that supports querying and manipulating objects at runtime. It can be used as part of the standard configuration, XML or annotation based, but can also be evaluated directly by the application code. It allows you to overcome the limitation of using only fixed values. It can be used for bean definitions in both XML- and annotation-based configurations. There is a facility to access system, environment and context parameters.

I have just covered thing that I would generally need or have run into... there is however quite a bit more information within the Spring documentation

So using Maven first thing I needed was to add following:



Using SpEL in Code:

Below I have examples code of: Setting a value, Calling a constructor, creating variables, calling a static function, all the basic operators, the instanceof operator and even the ternary if.

Using SpEL in XML Config: As with the Java code, here is the same functionality within you Spring application XML.

Using SpEL in Annotations:
And then again will the @Value annotation.