Do the least amount of work possible
That is the key principle that will make you more productive, will help you deliver your project on time and within budget, and achieve more. This may sound counter-intuitive at first. Bear with me.
We coders love coding stuff. Stuff that’s functional and clever and a challenge to build. That’s great, this is what keeps us in the game. However, to deliver a system, we have to focus this drive in the right direction.
Your software is supposed to solve a problem. Be that sending and receiving email, payroll processing, or the newest AAA game. What I mean by “do the least amount of work” is that whatever your problem, build the things that directly contribute to the solution, nothing more.
That’s easier said than done, because in practice it is often unclear how much something contributes to the final result, or if at all. For example, building debugging functionality into a system could be considered critical or extra, depending on your point of view. Factors like the life-cycle stage your software is in — for example, is it a prototype or a launched product — affect this as well. All that means is that there is no hard and fast rule to decide what is worthwhile to build. It’s all in the context.
How to
To trim down the work you have to do, you should ask the following three questions for every feature and improvement you are considering.
- Will my software do its job without this feature?
This is the most obvious question, and the single most powerful tool in your toolkit. But in the excitement of brainstorming ideas, all to often we forget to ask it and act on the answer. Again, if you can launch without a feature, don’t build it. - Does the feature have to support all corner cases, or can I apply the 80/20 rule?
Once you have determined that you really need a feature, try to keep it as small as possible. Sometimes this is a pure engineering question, sometimes this is a product question. It’s not always OK to exclude some corner cases, but if you can, do it. - Are there libraries or services that provide this feature?
If a stable library or service exists that already implements your feature, or much of it, not using that library is a major risk. Writing your own version guarantees you will make your own mistakes, many of which the library maintainers have already made and fixed. You are creating extra work and risk, which will slow you down.
There true power lies
Judiciously not writing code means you are not creating bugs, not creating complexity, and not creating maintenance burden. In addition to launching faster because you save time writing code, you also launch faster because you save time by not having to fix bugs you didn’t create.
Required Reading
- Plan to Throw One Away, in Jr, Frederick Brooks. 1995. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition.
- Martin, Robert C. 2008. Clean Code: A Handbook of Agile Software Craftsmanship.