Ayende @ Rahien

Refunds available at head office

Software architecture with nail guns

As you probably know, I get called quite a lot to customers to “assist” in failing or problematic software projects. Maybe the performance isn’t nearly what it should be, maybe it is so very hard to make changes, maybe it is… one of the thousand and one things that can go wrong, and usually does.

Internally, I divide those projects into two broad categories: The stupid and the nail guns.

I rarely get called to projects that fall under the stupid category. When it happens, it is usually because someone new came in, looked at the codebase and called for help. I love working with stupid code bases. They are easy to understand, if hard to work with, and it is pretty obvious what is wrong. And the team is usually very receptive about getting advice on how to fix it.

But I usually am called for nail gun projects, and those are so much more complex…

But before I can talk about them, I need to explain first what I meant when I say “nail gun projects”. Consider an interesting fact. Absolutely no one will publish an article saying “we did nothing special, we had nothing out of the ordinary, and we shipped roughly on time, roughly on budget and with about the expected feature set. The client was reasonably happy.” And even if someone would post that, no one would read it.

Think about your life, as an example. You wake up, walk the dogs, take kids to school, go to work, come back from work, fall asleep reading this sentence, watch some TV, eat along the way, sleep. Rinse, repeat.

Now, let us go and look at the paper. At the time of this writing, those were the top stories at CNN:

Hopefully, there is a big disconnect between your life and those sort of news.

Now, let us think about the sort of posts, articles and books that you have been reading. You won’t find any book called: "Delivering OK projects”

And most of the literature about software projects is on one of two ends: We did something incredibly hard, and we did it well or we did something (obvious, usually) and we failed really badly. People who read those books tend to look at those books (either kind) and almost blindly adopt the suggested practices. Usually without looking at that section called “When it is appropriate to do what we do”.

Probably the best example is the waterfall methodology, originated in the 1970  paper "Managing the Development of Large Software Systems" from Winston W. Royce.

From the paper:

…the implementation described above is risky and invites failure

As you can imagine, no one actually listened, and the rest is history.

How about those nail guns again?

Well, imagine that you are a contractor, and here are you tools of the trade:

They are good tools, and they served you well for a while. But now you are reading about “Nail guns usage for better, faster and more effective framing or roofing". In the study, you read how there was a need to nail 3,000 shingles and using a nail gun the team was successfully able to complete the task with higher efficiency over the use of the standard hammer.

Being a conscientious professional, you head the advice and immediately buy the best nail gun you can find:

(This is just a random nail gun picture, I don’t know what brand, nor really care.)

And indeed, a nail gun is a great tool when you need to nail a lot of things very fast. But it is a highly effective tool that is extremely limited in what it can do.

But you know that a nail gun is 333% more efficient than the hammer, so you throw it away. And then you get a request: Can you hang this picture on the wall, please?

It would be easy with a hammer, but with a nail gun:

It isn’t the stupid / lazy / ignorant people that go for the nail gun solutions.

It is the really hard working people, the guys who really try to make things better. Of course, what usually happen is this:

 

And here we get back to the projects that I usually get called for. Those are projects that were created by really smart people, with the best of intentions, and with the clear understanding that they want to get quality stuff done.

The problem is that they are using Nail Guns for the architecture. For example, let us just look at this post. And the end is already written.

Comments

PeterB
02/11/2013 10:55 AM by
PeterB

That's not a nail gun, that's a screw gun (nails come in strip loaders for magazines, screw come in belts)

A screw gun gives you precise control of torque and depth of screw penetration. It's a very fine tool indeed. It does a much better job than a nail gun and is nearly as fast. It is also better than a hammer and nail for hanging a picture

You need to get out more, and play with some real toys!

Frank Quednau
02/11/2013 02:03 PM by
Frank Quednau

Q. How many geeks does it take to ruin a joke? A. You mean nerd, not geek. And not joke, but riddle. Proceed.

Kent
02/11/2013 02:31 PM by
Kent

I'd be curious to hear more about your approach once you enter into those situations. Do you have a methodology that you use in mitigating the current scenario to get them to the agreed upon ideal state? Do you first focus on process (CI, Source Control, TDD, BDD, et al.) or on just getting things working. I realize that every one of these is situation dependent but it would be interesting to see if you developed any best practices in this.

Ayende Rahien
02/11/2013 02:34 PM by
Ayende Rahien

Kent, Get things working, have an SCM, don't spend a lot of time building infrastructure. Those are about the only real guidelines that I can express easily. The rest are really situation dependent. Although you can probably guess from this blog how I would react

Trystan Spangler
02/11/2013 05:32 PM by
Trystan Spangler

Yeah, some jump at the opportunity to add abstractions whenever they can. Others feel fine copy and pasting static methods over a thousand lines long. What are some early warning signs of using a nail gun when a hammer would be fine? What are some signs that you should start using a hammer and stop trying to punch the nail in with your fist?

Frank Quednau
02/11/2013 08:17 PM by
Frank Quednau

Just the other day one guy told me that abstractions can be a source of creativity. I found that statement interesting. Indeed, finding the correct abstraction can be an act that brings structure and organization to the code base. Alas, this cannot really happen in advance, but must be part of the evolutionary process.

Carsten
02/12/2013 09:01 AM by
Carsten

Spot on. I believe you also mentioned somewhere else the root cause: Cargo-Cult. But, why do you call these people smart? Choosing the right tool is a mater of professionalism. You’d also expect a surgeon not to use the nail gun.

Nick
02/12/2013 09:50 AM by
Nick

great use of images

Alwin
02/12/2013 07:45 PM by
Alwin

Surgeons actually use a stapler gun IIRC.

I loved the "Limit your abstractions" blog series, was a real eye-opener.

 Anthony Your
02/13/2013 03:45 AM by
Anthony Your

I loved this article because it very true...and I also was engineer who made nailguns.

As previously stated, you picture is of a screw gun. Which is "case and point" of your article. You really don't understand all of the options out there for fastening (screw gun vs coil nailer vs finisher nailer, etc.) but you choose one because it's got power and seems pretty cool. What the DYI guy doesn't understand is that it takes a lot more effort and money to do the same, small job. The ROI of getting an air compressor and dragging it out and using more expensive fasteners usually doesn't payoff for the weekend warrior. The analogy can be easily extended to coding.

Comments have been closed on this topic.