Thou shalt do your coding in small increments. No work item may be longer than one day. And if thy work is unfinished at the end of the day, cut it off, and cast from thee. We heard it, believe it and are ready to die for it.
Always?
Here’s an example. Recently I spent over two weeks on a single development task. It had several moving parts that I had to create from scratch, carefully designing each of them and their interactions. Together they form a system that must be as robust as possible, otherwise our users won’t be able to use our application at all (hello, Web Start!). Finally, I tried to make it as transparent and as maintainable as possible.
I took the iterative approach. Create a spike or two. Lay out some high-level design and test. Implement some detail. Another spike. Another detail. An a-ha moment, step back and rewrite. You know how it goes.
Now, it was an all-or-nothing piece of functionality. It was critical that everything perfectly fits together and there are no holes. I just had to grasp the whole thing, even though it took days. Secondly, there were no parts that made much sense individually. Design and interfaces varied wildly, as is often the case in the young, unstable stage of development.
Sometimes your task is just like that. It simply is too big for one day or even one week, and too critical and cohesive to be partitioned.
Here’s an advice.
When you have to leave, what is the best moment to stop? It’s when you’re done with the part you were working on now, right? And then, when you get back to it on Monday, you spend a few lazy sleepy hours trying to figure out where you left 3 days ago? Wrong!
When you’re leaving, leave a failing test. Code that fails to compile. A bug that jumps at you and tries to bite your head off as soon as you launch. When you return, you’ll see the fire and jump right in to action. You will know exactly where you left, and won’t take long to figure out what to do next.
Thanks to Tynan for helping me realize it. Though his post is a general lifestyle advice, I think it can be applied to software engineering as well.
I’m reminded of an author, who would stop in the middle of a sentence at the end of each day. That way, he’d have much less trouble getting back into groove of where he had been the previous day.
Same concept, different discipline.
I disagree. Imagine this scenario:
– Working on Project A, I leave my code broken for the day
– The next morning, I have an email from my boss telling me to switch to Project B
– Work on Project B for days/weeks/months
– User reports terrible bug in Project A, I need to fix it ASAP
– Hope to ship latest improvements along with the bug fix
– Try to get code running, but it’s difficult due to unfamiliarity
– End up reverting code to previous stable version and then fixing bug, instead of shipping newer version
Your advice may work in the best case, but I prefer to plan for the worst.
This scares me… I tend to loose sleep at night trying to figure out why things won’t work when I leave code in such a state at the end of the day; I can’t help but obsess over problems like that.
This is so very true. If I am struggling with a piece of code and have to leave on Friday (generally struggling means that you lost your focus and it’s time to leave anyhow) I purposely put a compile error at the exact spot I was staring at so I know for sure I won’t forget what fragment of the code was baffling me before the weekend. Works wonders, especially if you are working on a problem that indeed needs multiple parts to tie together as they’ll all be dancing through your mind all weekend and you will lose track.
There’s no way I can leave if there’s a fire to put out. It’d ruin my entire weekend!
When I have to leave code in middle (especially if longer than over night) – I leave thoughts and instructions about what I was thinking and what needs to do in the code where I was next going to work – such as I can’t compile/run until I have dealt with them. Most IDEs will open projects as it was when you shut down so it is right under your nose.
@foobaz
If I have to fix a bug in released code – I will go to code that is released (usually I have a clean copy of that on computer anyway, but if need be I’d check it out) – as I would intend releasing just that fix and just that fix as that would be safest, require least testing and quickest to release.
If I am working on new features/release then I would expect that to go through a suite of regression and user acceptance tests irrespective of what my automated tests show.
So it is irrelevant what state I leave the code I am working on just to worry about some hypothetical very low probability issue is
What I do is, I just stop writing code and start writing text explaining what I was doing when I left off.
I use the
#error
macro to ensure that it can’t compile, and I leave a little brain dump of my state at the point where I was working.
It is better to leave it in a state that won’t compile (and not checked in, of course so you don’t break the build) than to leave something “working” that isn’t really complete and thus has subtle bugs… or to write crap code just to “finish” it in a rush or when you’re tired.
Deadly post – I’ve gotten similar value out of leaving uncomitted code, so when I sit down, I just view the diff, and it’s as if the stack trace from the work I was doing suddenly loads straight back into my head.
I started doing this a while ago. Lately I’ve been putting what I have to do next straight into code without commenting it. Come monday morning the compile error will take me straight there and the message should be enough to get my brain ticking along.
Ray, I do the same thing. I review the commit diff, to understand what I did.