We are what we repeatedly code
Seven seconds
That’s how long it takes to split a piece of code into a base class.
Five seconds
That’s how long it takes to add an XML-doc comment to a method.
Developers have a strange psychology when it comes to code quality. If you’re familiar with Maslow’s hierarchy of needs, the equivalent for most developers might be:
For many developers, the basic rule of thumb is that if no one is watching, you don’t have to do a good job. After all, if you plan to throw the code away at the end of the week, why bother refactoring code or creating interfaces or adding comments? And when you’re a week away from shipping, who has time for writing unit tests?
I recently wrote some code to do a load of reflection on some assemblies, and to combine them with Work Items from TFS to produce an interesting report. When I wrote the tool, it was originally designed as a throw-away example application - I just wanted to see what the data would look like.
I could have written the tool as one huge Main method in a console application. Yet, instead, it’s all nicely factored. There are base classes, adapters to reduce the dependencies on the outside systems, encapsulation, interfaces, a couple of occurrences of the strategy pattern, and even the odd XML-doc comment thrown in here and there. Hell, I even gave the DLL a fully qualified company namespace. It’s not perfect, but if someone stole my hard disk and put the code online for the world to see, I wouldn’t be embarrassed.
Every step along the way I could have reasoned for the lazy option. I could have left those comments out - I knew what it was doing, so who cares? I could have avoided the adapters - after all, I’m probably not going to stop using TFS. I could have avoided the base classes - “clipboard inheritance” is often much quicker than putting stuff in a base class, or splitting it out into a strategy pattern. Since the code was never going to see the light of day, why bother making it look presentable?
We are what we repeatedly do.
Excellence, then, is not an act, but a habit.
When we’re in a rush and deadlines loom, our excuse for writing poor code is that we don’t have time to do it right. When deadlines are months away and we have all the time in the world, our excuse is that maintenance developers may not understand it when we use “complicated” things like inheritance. When we’re prototyping something to demonstrate that a technique will work, our excuse is that it doesn’t have to go into production. When we’re writing throw-away code, our excuse is that it will be gone within a week. When we write code at home for ourselves, our excuse is that no one else will see it.
The best developers I know write great quality code every time they touch an IDE. This is because they realize that writing good code is something you have to practice, something that you have to do over and over again to be able to do right. They realize that writing great code is something you do all of the time, not something you save for a party trick.
You don’t learn to write good comments by reading Code Complete; you learn by writing comments over and over again. You don’t learn to refactor code by reading Refactoring; you learn it by doing it over and over again. If you don’t write great quality code 100% of the time, every time, how can you possibly expect to write it when the situation really depends on it?
If we write prototypes and throwaway code at the same level of quality that we say we do on our résumés, the code we write at work in production may someday approach that same level of quality. And it won’t be something we do consciously - it will be a subconscious thing, ingrained in us through habit and repetition.
I don’t buy the excuse that writing good-quality code takes too long. Sure, you can go overboard - you probably don’t need to implement every design pattern in the GOF to test a new sorting algorithm. But programming to an interface, adding the odd comment, following good naming conventions and writing some simple unit tests does not take any time at all, not when you practice them over and over.
Even when you are supposed to ship at the end of the week, I am sure you can afford seven seconds to move code into a base class. And if it takes you more than seven seconds, you have not been practicing enough.
Filed under: Uncategorized
Hi Paul,
I’m a Software Architect from Germany, reading your blog for quite a while now and I appreciate your often controversial ideas and arguments. I have to state that I don’t agree with a lot of them, especially not with your “Databinding fanaticism” :-), but I like open-minded guys with fresh ideas who show you a new point of view from time to time. Like your great idea of “the Domain Tree” (http://www.paulstovell.net/blog/index.php/the-domain-tree/).
But this time I believe you are not just wrong. I’m not sure about your influence among the .Net developer community, but even if only a fraction will read this entry and believe what you are saying it might cost their companies thousands of dollars or even more. And that’s because unlike what you are saying you won’t get quality for nothing. It costs money. A lot of money. You can’t even say what that means, quality, without giving the concrete context in which you are talking about this issue, without saying what’s important for you or your customer.
The ISO 9000 definition of quality is: “Degree to which a set of inherent characteristic fulfills requirements” Don’t you think the requirements will differ from a prototype project to a large scale enterprise system? Do you really think the inherent requirements of your throw-away TFS sample application contained “reusability”?
So if your boss asks you to do a POC to prove some technical statement or anything else, you’d tell him it will take almost the same amount of time (and money) the final product would cost just because you as a professional developer can’t write code without all these nifty little patterns, reusability aspects, high quality documentation and whatever else?
I’m pretty sure you’ve heard of YAGNI (http://en.wikipedia.org/wiki/You_Ain’t_Gonna_Need_It)?! So don’t introduce any adapter pattern before you need it. Do you need it in a throw-away sample? Obviously not, so you’ve wasted time. And money.
I guess I understand what you’d like to say, but with all these concrete examples you’ve given it leads into the wrong direction.
Hope you like controversies as much as me, for me it’s one of the most important aspects of blogging, getting feedback from the community. Hope also I didn’t sound rude, my english is not good enough to express everything I’d like to say in the way I’d like to say it.
Keep up all the good work here on your blog!
Björn
Especially if you use ReSharper.
Well said Paul. I annoys me no end when you try to get other developers to do things like unit tests and you get excuses like “oh,but it’s only a prototype | small site | internal tool”. That prototype code more often than not ends up in the shipping app, and any time you spend getting it right now is going to save you hours down the track when you hit maintanence time.
Free Instructor led WPF Hands On Lab -Update
I have had a lot of interest in my post: Free day long instructor led Windows Presentation Hands on lab
One thing! God bless ya lad.
I do wish everything was that easy to be perfected though!
Hi Björn,
While you’re right, perfecting the code for a throwaway application over and over again might cost a company thousands of dollars, for the most part doing things “well” (as opposed to doing them “perfectly”) doesn’t take much more effort than doing a bad job.
Let’s use naming standards as an example. If it’s company policy to start all methods with a capital letter (Pascal casing) then it takes no more keystrokes to follow that standard than it takes to not follow it. Yet, for some reason, developers have this strange mentality that when they’re writing code no one else will read they don’t need to follow the standards. That’s fine in isolation, but when they come to writing production code and time is critical, they’ll fall back to these lazy ways (without realizing it) and all of a sudden this “bad code” seeps into their production system.
Let’s take the case of creating a simple adapter or a base class or designing an interface. I’d estimate that I can create a wrapper around a class with the 5 properties I need and a factory method in less than 20 seconds. Are you honestly telling me that your P.O.C. is in such a rush that you can’t afford 20 seconds? Even for a week-long prototype, doing a slightly better job is going to add up to perhaps an hour or two (although in that case it’s probably more likely to save you time, since we often find a use for these good designs as soon as we’ve added them).
If we’re going to argue about costs, we need to take the long term costs into account. Doing a prototype “well” (not perfect, but not bad either) isn’t just about making a good prototype - it’s about instilling a habit of continually writing good, solid code. Developers who write bad prototypes will write bad production systems, especially when time becomes critical.
I know some developers who spend their time prototyping applications over and over, which will never make it into production. They don’t expect anyone else to look at the code, and so they do a half-assed job with it every time (I know; I’ve had to read through their code in the past when it comes to implementing). The end result? They *can’t* write good code, because they don’t know how, because they don’t practice it over and over again. Like I said in my post, knowing how to write good code doesn’t come from reading books - it comes from writing it over and over. Every time you write bad code, your ability to write good code decreases.
Ask yourself what is more expensive - a good developer who spends a little longer on prototypes but writes great production code, or a bad developer who writes bad code on production systems because it’s the only code they know how to write. In my mind, there isn’t many people who fall between that gap.
Paul
[…] you write crap code Posted by Andrew Matthews under Readify Paul Stovell has written a good post calling for people to make writing good code a habit they employ every […]
yeah… it’s even painful to watch other developers that just don’t care about comments, refactoring, naming conventions, etc, as long as “it works”… you (as a developer) are what you code
[…] I would also recommend you to read Paul Stovell post “We are what we repeatedly code”. […]
[…] We Are What We Repeatedly Code - Talk about how practicing good coding habits becomes normal over time, and that should always be something to strive towards. […]
[…] This morning Signal vs. Noise linked to a post by Paul Stovell called We are what we repeatedly code: […]
[…] We are what we repeatedly code Tagged as: development software interesting « Alison Krauss Concert […]
Quality is relative: for some people, quality is a minimal number of abstrations and “overhead” in terms of unnecessary interfaces, classes, and general ravioli code. In that sense what you call “good” code may be considered “crap” from someone who is paying the bills for the prototype, not because it takes you any longer to add the extra code, but because the end result may be harder to read for another person who has to convert that prototype into production.
Really it comes down to intrinsic complexity, derived from fundamental requirements, and synthetic complexity, that derived from rules and methodology adapted; sometimes minimizing both types of complexity is essential.