programming and human factors
by Jeff Atwood
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!
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!
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 6:52 AMI 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 2:17 AMI 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.
I agree with some of the conformity to standards issue, but not all. Some consistancy in coding standards, especially when working with teams, makes maintenance much easier. Note that I'm only really addressing coding and convention standards here. For instance, all variables on a program should follow an agreed-upon naming convention. Code for initialization, public methods, private methods, etc. should all be contained within regions. These kind of restrictions don't place too harsh of an onus upon the developers, but digging up where someone else's code is doing something strange is lot easier (or your code, because more than a couple of days after you wrote it, you start to wonder if you were drinking when you wrote it, or should start drinking before you continue).
Ironwil on August 13, 2009 1:17 PMIn 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 February 6, 2010 9:30 PMThe controlled destruction is an amazing thing. Once I looked in to the state of code, I found it's really scary and unable ot maintain more. There were a design and this design was broken according to everyone's convenience and made it hard to understand or work well. Even if we fix the issues, the other issues started popping up.
It was a kind of determination to remove the Junk code or break the existing code. Lot of functionalities which is fixed upon may break but that we've to take care. But In the last 1-2 years, It was amazing experience of controlled destruction and it got succeeded!
Sarat on September 20, 2010 9:08 PMI have a sticky note over my desk that says, "If you break it, you will learn." It's a philosophy one of my favorite (fearless) colleagues follows, and the sticky serves as a reminder and prompt to be just as fearless.
WWLoriHC on September 20, 2010 9:17 PM‘If you want truly to understand something, try to change it.’ — Kurt Lewin
Milanskoric on September 21, 2010 12:22 AMA decent set of tests can help reduce the fear. If you don't have tests, start the learning exercise by writing some. Or is that cheating?
Petecordell on September 21, 2010 6:01 AM100% agree in theory and in practice. However, I work in an enterprise where my boss^4 recently told a Global Town Hall meeting that reducing risk is our #1 priority. Now, I'm experienced enough to understand that properly breaking things in development reduces the risk of improperly breaking things in production. But how do we keep junior developers from responding to the risk reduction imperative by shitting their pants any time something (that they didn't even check in) doesn't compile?
Matthewkane on September 21, 2010 6:47 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |