The art of time management is usually a matter of ranking your items by importance and urgency, and prioritising according to how high things appear on each axis. But most books, articles and seminars on the topic stop there. Spending a few minutes each day doing something that is neither particularly important, nor particularly urgent, but that has a beneficial outcome, has value.
I’m really sleepy today. Finding it very hard to concentrate in work. I’ve spent most of the week out of the office preparing for an exam. It’s been years since I’ve had to sit an exam and I found the whole experience rather strange. My first problem was trying to write for three hours! I don’t really spend a lot of time writing anymore. I do make handwritten notes of meetings but these don’t compare to writing essays under pressure in an exam. I wanted to have a word processor. I also have more problems with the concept of exams than I’ve ever had in the past. I’m studying law and it seems that to pass the exam I need to learn lots of different Acts of Parliament, EC laws and cases. The exam was weighted much more strongly towards memory than application. What is the point of this? If I want to know the details of “the rights of migrant workers’ families” I will look it up. It’s so easy to find this information once you have some idea of the sort of thing to look for. Do lawyers really have to know the “Sale of Goods Act” off by heart to be able to give people advice on consumer problems?
Tony got a new scanner and now I want one too. I scanned one photograph and now I’m hooked. I still can’t see me moving to a digital camera though.
I have heard it said that bad code has a smell. Today I’m learning that some code also has a sound. Not a sound that I hear by looking at the code but a sound that is made by the programmers trying to use it. From across the desk I can tell that the CPAN module they are trying to use is badly written. Actually from the sounds drifting across the desk I would say it’s the worst piece of code they’ve had to deal with in weeks. It’s never good when the programmers say things like “What?”, “Yuck!” and “Eugh!” and then start to shudder at the horrors of what they are looking at. I don’t need to see this module to agree that we should spend the time refactoring it before using it. Based on their reaction I think I’ll hide on my side of the room until they’re finished.
You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.
– Martin Fowler, Technical Debt
I really like this metaphor. I’ve spent hours debating over whether we should take the quick and nasty hack or write the code properly.