Friday, May 04, 2012

The Code Also Rises

Can you write like Ernest Hemingway? Why not? He hardly used any big words. His sentences and paragraphs were short. His novel The Old Man and the Sea, published in 1951 and which I read nearly forty years ago, isn't even a hundred pages long. It was just about a old guy who went fishing. Why can't you write like Ernest Hemingway? How hard could it be?

Pretty damned hard, as it turns out. It's not about the act of writing words on a page. It's about knowing what words to write. Which is why Hemingway was awarded a Nobel Prize in Literature in 1954.

How hard can it be to write reliable, efficient, maintainable software? Take a look at the source code. It hardly has any big words. Each line isn't that long. A typical function takes up less than a screen. Some programs aren't even a hundred screens long. Why can't everyone write software? How hard could it be?

Pretty damned hard. It's not about the act of typing source code into an editor. It's about knowing what source code to type. And just like Hemingway, who was known for his spare, tight prose, knowing what source code not to type. A good software developer is no more a fungible commodity than a Nobel Prize winning author.

How hard can it be to manage? Take a look at a manager. He spends most of his time reading email, or sitting in meetings. Sometimes he wanders around and chats with people. He looks at spread sheets and documents. He goes to lunch. How hard could it be?

I think we both know where this is going.

3 comments:

Todd Blachowiak said...

Doesn't good code depend on the metric used to measure the code?

Does it make money? Is it elegant? Is it understandable/maintainable? Did it get completed on time with the expected quality? How long is the life of the code?

Is (the code/a book) ever finished from the authors perspective?

I've seen really bad code make lots of money and I've seen really good code make nothing. Which is better?

Chip Overclock said...

Code which accomplishes its intended purpose is successful. It it's intended purpose is to generate revenue, code that does not generate revenue is not successful. If you don't know why you're writing a piece of code, maybe it's time to think about not writing it.

This next point is worthy of at least one entire article all by itself. There is a strong tendency in all domains to seek short term value over long term value. That may or may not be appropriate. Maximizing value from a code base in the short term may make it more difficult (indeed, impossible) to extract value in the long term. This is especially true if the developers rack up a lot of technical debt which they fail to address. For some goals, that may be okay.

One of the important skills in any endeavor is knowing when to call it "done", quit, and move on. And when it's appropriate to revisit. So: yes, some things are indeed finished. Successful products however are inevitably subject to the adaptive maintenance I mentioned in the article just prior to this. So in that respect, some things can never be finished.

Anonymous said...

Chip,
You missed the chance to reiterate the importance of defining "done" before you start any task. As an advocate of TDD, I expected you do emphasize this key point.

Ken