How do you know where to start when you sit in front of your screen in the morning? Half of the developers population will probably start with a cup of coffee, some will visit Slashdot or Channel 9 (that's me!). There is, however, a breed of developers, that starts by checking out the fresh code and gets to hacking right away. If you are this kind of developer, this little tip is for you. Procrastinators already know what to do.
How often do you as yourself a questions like: what do I start with today? Or what was I working on yesterday? How often do you browse your post-it notes to pick the next task and you're lost? If you often find yourself in situations like these, there is a very helpful tip I learned from Kent Beck's Test Driven Development: By Example. The trick is: leave a broken test. The last thing you do before you turn off your screen is to write a test that fails. Name it appropriately so that you know what behavior it tests and make it fail. Write a failing assert or just leave Assert.Fail call. When you sit in front of your IDE next morning and start with running your tests, you will have a clear sign of where you finished yesterday and what you should implement next. This is especially useful to have a test like this on Monday. I don't work during the weekends, so I always find it very helpful to restore the context in a couple of seconds.
There is a little issue in this method and this issue is teamwork. By no means, don't check in your failing test as others may think it is... well, a broken test. A bug. Something they need to fix ASAP (if you have loose code ownership). They will either blame you (not very likely but possible) or fix it themselves. Either way, leaving a broken test committed into the source code repository is clearly not a good idea. If you have any comments or ideas about this tip, please share!
04-05-2007 8:28 AM