Discovering what life is about

Maintaining Discipline

Maintaining Discipline
Last weekend, I made a huge mistake.

As I've alluded to in previous posts, I'm currently working hard full-time on my prototype for a startup venture, and that means I've been coding a lot. Around the time when the aforementioned mistake occurred, I was working on some pretty feature-rich tasks, and I just wanted to get them done. I felt like I'd been treading water for hours, and I was tired, and I needed to get a new build out. Because I'd set a goal for myself of getting features X,Y and Z done that evening, I was despairing the time still in front of me. I had tests to write for each of the new features I wanted to add, and some code segments were going to be rather duplicitous and would be begging to be DRY-ed up. Unfortunately (for the code), I was tired and in a foul mood and I decided that if I wanted to get to bed I would just have to slap the code in and worry about the other crap later. In 30 minutes, I had a new build on the server (tested by me in a web browser) and I was in bed. Woo-hoo, a victory every insomniac can appreciate!

Then the next morning came. I opened up my code editor, and realized that I was faced with a conundrum. Usually the very first thing I do, before checking my backlog to see what I want to work on next, is run my tests (even though I haven't changed anything from the night before). That gives me the confidence to move forward knowing that everything I've written in the past is still doing what I intended for it to do. That morning I had no such confidence. I couldn't even press the button to start them because I was afraid to see what my test suite would look like; as I recalled my actions of the night before, I was overcome by a feeling that could best be described as a hacking-hangover, complete with all the remorse that accompanies the alcoholic variety. I had broken discipline, and now I was going to pay. I had an unpleasent decision to make: lose productivity that morning to clean up what I'd done the night before (write all the tests I skipped, abstract out all the junk I'd hardcoded, refactor out duplicated blocks, the list goes on), or press on adding more features while basically blind as to their effect (save a manual test-fest through a browser).

Of course, being the responsible steward of the code that I am, I chose the former, but during those next few hours I kept thinking to myself "what the f%#@ made me think THIS was a good idea?". I couldn't believe that after everything I've read, written, and experienced that I'd still fallen for the lie that I could just fudge the process "just this once". Please, I beg of you, learn from my mistakes!

Here's what goes through my mind everytime this happens:

- doing any task takes time
- writing tests is a task (1)
- writing code is a task (2)
- refactoring (code and tests) is a task (3)
- only task-2 actually contributes to production features
- THEREFORE task-2 alone will produce the same end result as all three tasks, and in less time.
- I'm "tired" [substitute "bored"/"hungry"/"impatient"/"an idiot"]

These are the ingredients for a most unpleasent recipie. You jam out some of the ugliest stuff you've ever written, but your goals are accomplished, so you can move on. Do NOT fall for that crap!

You must remind yourself, in your weaker moments, that you use this process for a reason. One might say "but Ethan, I DON'T use that process, by 'sacrificing' your automated testing and refactoring you actually were just coding the way I do every day!". If that works for you, great, but that won't cut it for me (or anyone who ever works for me). I make mistakes all the time: I write tests so that no one else ever has to find out. I am lazy and hate doing maintenance work: I refactor my code so it will take as little time as possible. When I don't do those things, I hurt myself and create debt I'm just going to have to pay back later with interest.

What interest?, you might ask. Aren't you just defering a set amount of work until another day?

I feel that the answer to that question is no, for a couple reasons.

1) writing each test BEFORE you write the code to pass it (TDD) means that the code only does what you need it to do, and you don't waste time prematurely throwing in bits you won't need.

2) even if you write the tests afterwards, doing it in the same session means that you still have the code fresh in your mind so you can test what you need to quickly and efficiently. Doing it later means, in the best case, that you will have to spend a little time refreshing yourself on what that block of code does. Worst case, you will feel rushed and anxious to get on to something that's actually producing new features, and you will miss things that you will have to come back and fix later costing MORE time.

3) belated refactoring means that you only remember that you have to change that code in more than one place after you only changed it in one place and it broke. Try saying THAT five times fast.

4)You might not end up coming back to it at all, costing you or somebody else time when they have to fix a bug or add a feature and they have no easy way to tell if they've broken anything in the process.

If you are tired, go to bed, you can finish in the morning; Or, go ahead and play the hero for a night by staying up and doing it the right way. But for God's sake, the worst possible thing you can do is feel that you're doing yourself a favor by cutting some corners for a quick payoff. Reader, I implore you, don't let my failings be needlessly repeated.

 Ref :


Share |
add a comment...

0 Comment

Leave a Comment