Learn To Do Just Enough
From Programmer 97-things
I have yet to work on a software development in which time has never been a key factor to which developers need to be aware. There are numerous approaches to time management, most independent of the task being undertaken. Management are always asking software developers if they have finished the current task'. In my experience, this question should always be rephrased to 'have I done enough'.
How do you know you have done enough?
As a young developer, I remember my manager asking the management question for the module I was working on. For days, I reported it was 95% complete as I always had one or two more tests to complete. Now the reason I was never saying that my module was 100% complete was because I was spending all of my time fixing obscure faults based on more and more unusual conditions. What I should have done was released the module because the module did work in the manner that the customer intended. If I look back over my early development career, probably 75% of my time was spent on implementing and testing error conditions, which could only occur in the module but could not occur in the integrated application.
Meeting the requirements is clearly one measure in establishing if the task is complete. However, it is very unusual to have such a well defined specification that it is very clear that you have completely finished. A more typical scenario is that you think you have finished because it passes all of the tests, including some error conditions, that you have thought about (and maybe a few extra ones which you colleagues or customer have contributed). Now for some applications, I am very keen that plenty of time is allocated to testing these conditions because the consequence of failure is severe. However, in other cases, the consequence of failure could just be a minor inconvenience which can be addressed by appropriate user education. So in establishing if you have 'done enough' you need to ask a number of questions
- Are all of the requirements really necessary? Ask the 'why' question to see if your customer really needs the requirement, particularly for the requirements related to error handling.
- Remember the Pareto principle. Are you spending 80% of your time delivering 20% of your application (and experience says that this is the part of the application that is rarely used)?
- Adopt a 'Design by contract' approach. Can you concentrate on the normal circumstances and consider the abnormal later (if required)?
In my experience, some or all of these approaches will help you meet your goal of delivering the necessary functionality on time, and at the same time doing just enough development without over embellishing the code with functionality which is rarely used.
This work is licensed under a Creative Commons Attribution 3