Sunday, October 26, 2008

Seriously...Stop Writing Code

Pick Me!

In my last year of university I had the privilege of being flown out to Toronto to attend VS Live! 2004. It was the first developer conference I'd been to (at least of scale), and and even though it was years ago there are a lot or moments that still resonate with me today.

One such moment was during an event called Midnight Madness. Some .NET evangelist was working the crowd into a near frenzy. The excitement may have been related to the subsidized bar, but either way the crowd was fully engaged.

I remember the speaker calling out to the crowd as he described his perfect development team.

"How many of you have written your own UI controls?" he asked encouraging the crowd to respond by putting up his hand.

[Hands shot up and people cheered.]

"How many of you have written your own data structures, sorting algorithms, or math libraries?" he continued by putting his hand in the air again?

[The crowed continued to roar with some attendees now on their feet.]

"Well unfortunately..." he said pausing for effect. "I wouldn't hire any of you to be on my team..." he finished watching the crowd deflate.

[A hurt silence hung in the air while a lot of confused developers sat back down].

The speaker went on to explain one of the most important principles I've ever learned.

Good Developers Write Less Code

The first time you hear this it's a bit of a doozy. It's an incredibly hard discipline to instill because developers love to write code. It's probably related to why we became developers in the first place!

What makes the problem worse is the more clever you are more likely you are to to figure out a good solution to a problem...and code it up. Moreover, you might see some opportunity for reuse in your solution...and make a library out of it. If what you just wrote already exists (even a little) then you're probably doing your team and your company a huge disservice.

Every line of code that you write has a huge cost associated with it, every line.

Each line needs to be:

  • Debugged
  • Commented (and comments need to be maintained as well)
  • Stored and Versioned
  • Tested/QA'd
  • Maintained/Updated
  • Read and understood by teammates
  • Deployed

The costs of ownership of for all that code you produce is huge, even if you happen to stay with the company and the requirements don't change (which is unlikely).

Code rots. It doesn't matter how elegant or well implemented the solution is, the system will inevitably get old and the requirements will shift. What was once your prized piece of work will soon become someone else's real problem. When was the last time you heard a developer say:

Developer 1: "Wow, I sure am glad I inherited all this code from [Developer 2]! Maintaining this system is going to be effortless in days to come, I can't wait until the change requests start to appear!

You just witnessed English that has never, and will never be uttered. Good developers aren't necessarily awesome coders, they're great at learning, troubleshooting and understanding. And most of all, they're extremely reluctant to write code, ideally because they understand the cost of ownership of those codes.

With a Gun To Your Head

Of course sooner or later you're going to have to write something...it is after all your job. The point I'm trying to make is that it should only be under extreme duress that you reach for the keyboard. Only after doing some serious research and asking around should you consider touching the home row. There are a lot of alternatives that can be exhausted prior to getting creative with your own solution. Tools like code generation, excellent 3rd party libraries, existing services/applications can not only speed up a project time line but save a lot of money down the stretch.

Is there really value in writing your own CRUD stored procedures for each entity in your data store? Consider generating them with some code gen tools.

Is there any value in writing your own Ajax grid or WYSIWIG editor? Buy one. If you're worried about the company going under then buy the source too.

Exceptions

There are of course exceptions, Joel Spolsky writes about a key exception that you can use as a guiding principle when it comes to deciding whether or not this is something you want to own and maintain in house.

If it's a core business function -- do it yourself, no matter what.

The point is that you're always going to want control over key business functions. If you outsource everything then there's no way you can be exceptional or offer core business functionality that's better than your competitors.

Enter the balancing act of what to own and what to outsource.

It's worth noting that I would be very careful about what you consider your core business functions. The more code you write the more expensive that differentiated service is going to cost you, and as a result, it will cost your customers more too.

Keep the costs in mind. Writing those solutions is fun especially when the problems are interesting, but we're not just developers, we're analysts too. The gold star really belongs with the developer that is selfless enough to have the customer's (and more importantly) the company's best interests at heart.

My Best,
Tyler

1 comment:

Brett Wejrowski said...

Wow. I love this idea. I am, unfortunately, one of those programmers who loves to write my own code. I am always nervous that a plugin or opensource program is going to do more harm than good, and I always say that I like to know exactly what my code is doing all the time.

However, this article raises a really good point. Time is money, and on large projects, it just isn't feasible or practical to write your own code for everything.

A great programmer will write almost everything and do it well, but a great developer will use what's available to him to create something that does what its supposed to do; and he will not waste his own time doing it.

Great article, thanks.