How many times have you heard someone say—or maybe you’ve even said it yourself— “Yeah, it’s a hack. But we don’t have time to do it right.” Frankly, this one goes in the same category as popular rubbish like:
- “We don’t have time to write unit tests.”
- “We’re not paid to read technical journals and surf the web.”
- “I’m too busy to exercise.”
The problem is that we have a process addiction. I like the way Tom DeMarco described addiction in a talk he gave at the Boston SPIN. We usually think addiction is about doing something that’s bad for you but that makes you feel good. It is, but that’s an oversimplification.
Lets look at unit tests, for example. When you’re under the gun, who has time to write tests? Yes, automated tests are good. But when a month’s worth of new software needs to ship next week, we save time by skipping the tests, right?
Wrong! Yes, it is faster to code without tests… unless you care whether the software actually works. If you do care that it actually works, it’s much slower to debug masses of untested code, and faster to unit test. But we have this lie in our heads. We believe that coding without tests is faster. And don’t blame management. It’s easy to blame management for not having a clue, but we developers buy into the lies more than they do.
We have a desperate need. We are in pain. There is something that will relieve our pain, will meet our need. Just bang out the code as fast as you can, and pick up the pieces later. We know it’s bad for us, but we believe it will help us. And in the short term, it actually does seem to help. We do “write” the code. That is, we write software the same way a million monkeys write Shakespeare. But it is code, and we can tell management it’s “done.” And this bolsters our belief that skipping unit tests has gotten us out of our crisis.
But in the long term, it hurts us. And in this case, “long term” means two weeks. We can tell management we’ve done a month’s worth of work in only a week. But the software is not going to ship. It’ll be delayed for another two months while we sift through all the bugs and the interactions between bugs in thousands of lines of code. And during those months we’re going to be increasingly under the gun, and so we’ll take even more so-called short cuts. So make that three months. And since we’re working overtime and aren’t sleeping right and aren’t taking care of ourselves, we’ll make even more mistakes, and we’ll have to debug those, too. So make that four months.
So, one month versus four. Which is faster?
Similarly, you are paid for keeping up on the latest developments, and that means reading technical journals and blogs. This may not be an urgent activity, but it’s important, and it needs to get done.
And exercise! When developers go into crisis mode, they start skipping their afternoon walks and naps. That’s not just bad for you; it’s bad for your crisis, too. When you’re in a crisis, that’s exactly the time you need your mind about you. That’s the time you need to be well rested and in top shape. A healthy body means a healthy mind. When you’re in a crisis, that’s when you’re too busy not to exercise.
A process addiction unfortunately is systemic. And breaking it is hard. But as they say, the first step is to admit that you have a problem.
-TimK
True. Save now, loose later. *Sometimes* it can really be reasonable. Unfortunately our mind tends to avoid extra work “right now” too often
Hi, Artem. Thanks for writing. Yes, sometimes there is a real trade-off between a little more work now and a lot more later, but that’s not the scenario I was describing. What I’m talking about is the belief that a even little can be saved now. It’s the fact that we respond to pressure rather than actually making an intelligent choice.
I’m as lazy as the next guy. That’s why I love unit tests. I love being able to accomplish more with less work and less frustration. And by skipping unit tests, I’ve introduced bugs, and this happens more often than I want to admit. So, I’m Tim, and I’m a recovering process addict. I need to remind myself constantly that building quality into the design—and that’s what unit testing is about—seldom costs anything even in the short term, and never in the long term.
Sometimes I do hack together a solution, for example, but I know that the next time someone touches that code, he’ll need to refactor it before he does anything else. Otherwise, the hack will turn into a bug-ridden maintenance nightmare.
Unit testing comes immediately to mind because that’s a subject I’ve been thinking about at work. But we do the same thing with communication. (“Aw. I can’t walk all the way over to my teammate’s cubicle just to say ‘Hello.’ Not just now. I’m too busy.”) We do it with estimation and retrospectives. We do it with the build procedure, because it’s easier just to do it manually than to deal with automation issues. And then we have 3-month integration cycles (and slower release cycles), just because it takes a whole afternoon of developer time just to do a drop. At least I know each of these I have seen first hand, and I have been the sinner in some instances, a recovering sinner, saved by Grace.
-TimK
If the unit tests are not in place (e.g. because you company just doesn’t use unit testing consistently), then fixing without a test for the tomorrow demo can be faster and is faster. Unless you keep the tests up to date and run them at least daily there is always an “easy path” to do the testing for your small fix manually.
It does work and works well. It just works for the next week only. Two weeks later somebody else makes another fix that breaks your fix and there is no test in place to warn about it. However, for the next week the simple manual testing really works. After all usually it is just a manual examination of what a unit test would check automatically. And here the trap comes: if the manual test works for now, spend the time with testing later.
Yes, I agree with everything you say here. What if we’re so busy, we don’t have time for proper manual testing, either? (How many senior people on your team have checked in code without testing it? It happens all too often here.)
-TimK
carnival of the agilists, 20-apr-06
Welcome to the April 20th edition of the Carnival of Agilists – the blogroll pointing you to some of the latest thoughts in the agile community
[…] Kicking off this week’s carnival is J. Timothy King – a new blogger to our community – trying to Break Your Process Addiction. Welcome! […]