I <3 Steve McConnell*
Coding Horror
programming and human factors
by Jeff Atwood

November 04, 2004

Don't Be Afraid to Break Stuff

One warning sign I look for when working with other developers is fear of breaking the code. The absolute worst systems I've worked on are the ones where the developers practically tiptoe around the source code.

The main problem with fear of breaking the code is the implicit assumption that any code is really that good to begin with. All the code we write is broken. Your code. My code. Everyone's code. Software development isn't a science; it's a process of continual refinement.

Now, I'm not proposing that every developer start ripping through a stable, production codebase and start rewriting it as an exercise. There's certainly a learning curve that comes with any new codebase, and appropriate testing should always be performed. However, I firmly believe that the absolute best way to learn a system is to break it. Over and over. Start by breaking off a small piece. What happens when you turn that off? What are the consequences of deleting this variable? Does that function need to be here? If you can't break that codebase, and then piece it back together again-- in every way you can think of-- then you're going to be absolutely screwed when another developer breaks something. Or, even worse, a user breaks something. And they will, in ways you haven't even considered.

Once you've broken enough stuff, a new codebase stops being scary, and starts being.. sorta fun. Those broken windows will seem a lot less like intimidating roadblocks, and more like candidates for fixing-- or at least boarding over. And while you're at it, why not remodel the place, too? When it comes to software, controlled destruction breeds confidence.

The most direct way to improve as a software developer is to be absolutely fearless when it comes to changing your code. Developers who are afraid of broken code are developers who will never mature into professionals.

So, go ahead. Break stuff!

Posted by Jeff Atwood    View blog reactions

 

« HTTP Compression via HttpModule Is DVD the new VHS? »

 

Comments

Hi Jeff,
this is a very strong reminder for me to finally pick up a decent source code control system and start using it. I'm considering it for some time now, but as we're not using it at work I'm really on my own here in finding out which one best suites me. It should be something you can easily use on your own, without too many server hassles. The best thing would be some clientside system, as I wouldn't be able to convince other to install something on the network or spare server. I guess the best thing is just to give it a go and maybe in the end I can persuade others to go along... thanks!

Sikko2Go on November 5, 2004 02:13 AM

Yes, you definitely have the right idea-- you want to be under source control at all times!

Ned Batchelder has a few recent posts on source control that you might find interesting:

http://www.nedbatchelder.com/blog/index.html

Read the comments on those posts for more reader suggestions, too. For me, IDE integration is a key requirement.

Jeff Atwood on November 5, 2004 06:52 AM

In my opinion this type of person, who is afraid of breaking the code, is really afraid of learning the code. If you know the code front to back, or are confident that you could if you had to, breaking the code is not a big deal. It can always be fixed. If you don't think you have what it takes to dig into the code and learn how it does what it does, of course you'll be afraid to change anything.

Joel Hendrickson on November 11, 2004 08:33 PM

I agree completely. The best way to learn is by breaking things and then fixing them. And even if you don't "know the code from front to back", the only effective way to get there is by slowly breaking and fixing things, IMO.

Jeff Atwood on November 12, 2004 02:17 PM

I think it's not really about being afraid to edit code it's the idea some people have that the code is gold. You see that a lot in c++ and not so much in Java/c#. I find some people write code like it will last forever, Its like a baby that they have to cradle to sleep every night. I think thats a mistake. I have seen the most bizarre standards that require so much labor and in the end you get this legacy junk. Code should be thought of as disposable. I like it quick and short with small chunks. I also hate emphasis on consistancy. Some people would rather do something consistantly wrong ( or leave bugs in )than to try and address the fundamental flaw! which requires going deep.

No matter how good you are the second time you write it it's almost always better. Usually any developer of almost equal skill can improve on anything the second time. If you have a piece of code which is so complex that you can't re-write it without entering bugs then that is the best reason for doing so because the design is shit.
You get that a lot when you have massive classes or even methods with a million lines. You gotta chunk it up so that you can throw it out easier. just my 2c.

R.J. on December 29, 2006 12:00 PM







(hear it spoken)


(no HTML)




Content (c) 2008 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved.