Jun

10

Making Development Complex on Purpose

Posted by Keith McMillan

June 10, 2008 | 1 Comment

I’ve worked with a lot of software development professionals in the last twenty years, and I’ve noticed a curious phenomenon. I think we make work harder on ourselves. It mainly seems to happen with the smarter developers, which makes it all the more puzzling to me. First, I suppose a bit of background to help understand what I’m talking about.

I’ve spent the last decade or so doing software architecture, implementation and security, among a raft of other software development related stuff. I’m the type of guy who believes I’m not a good software architect if I don’t get my hands dirty. If I can’t prove to myself that the architecture works, then it’s no good. Put another way, I believe an architecture is a thesis, and it’s no good until it’s proved. This means that I get into the nuts and bolts details of implementation, as well as drawing at the whiteboard (and rare is the meeting where I don’t jump up to draw at the whiteboard).

Because of all this consulting work, I’ve gotten to work with lots of new technology, and on lots of new development projects. This is where the strangeness comes in. There have been all kinds of projects over the years where what we were doing wasn’t all that new and novel: there are only so many times you can write a contact management or order processing system before you know where all the sharp edges are. Or so you’d think…

The strangeness I’ve noticed is that if a project isn’t complicated enough, we make it more complicated. I’m increasingly convinced that we do it on purpose, although I think it’s subconscious, at least most of the time. We add in some whizbang new technology, or find some new wrinkle that keeps our interest: “Hey! We can use this new AJAX stuff that I’ve been reading about to do this!”

It’s as though we have to have a certain amount of risk in a project to keep us from dozing off. I don’t think it’s malicious, in fact I’m pretty sure people don’t even notice that they’re doing it, but I’ve seen it often enough to exclude this as simple coincidence.

So why do we do this to ourselves? Couldn’t we be perfectly content with doing it the same way we’ve done it the last half-dozen times? I don’t think we could. In part, it’s temperament. These are smart people that I see doing this, and frankly, I think they get bored. If they had to do it the same way they’ve done it before, where’s the fun in that?

I also think there’s a good business reason to look at the new technology. I admit, it’s risky to adopt some new technological wrinkle, but those wrinkles typically came about for a reason. They tend to make it faster, more flexible, or more extensible than what we had before. Sometimes, we couldn’t do before what we can do now, simply because hardware is faster and cheaper than it was before. When we did it last time, we said to ourselves “well, if we could have a 200 megabytes of memory, we could do this much more efficiently.” Well, now we can, so we can do it the new way.

The project manager part of me says “let’s not adopt a new risk that we don’t need, let’s do it the way we know will work,” but the techno-geek says “we can use the new XFire toolkit in order to create a web service, and we don’t need to be concerned about the network bandwidth because they just put in the new gigabit ethernet backbone at the data center. That way, we can enable the application to others who come along, rather than just us.” They both get a voice when it comes time to decide what to do, but I admit, I have a soft spot for the techno-geek.


Comments

RSS feed | Trackback URI

1 Comment »

Comment by Andy Kailhofer
2008-06-10 09:08:57

In their example, if they just finally put gigE in the data center, they’re not really techno-geeks. 🙂

Don’t mind me, I just spent the night fighting with firmware on a Proliant server while adding another disk array for a project with underestimated disk usage. It might have left me especially curmudgeony today.

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll