I have lost count of the times I have heard a developer exclaim ‘but I could write that in X days’ when discussing adopting an existing piece of technology developed somewhere else. This is usually given as a reason not to adopt an existing external solution but to instead write a custom solution with some minor improvement or feature. There are two big flaws in this line of reasoning.
The first is the assumption that you could create something with the same quality level as the existing solution in the stated number of days; most likely you will be lucky to have a functional prototype with minimal functionality. It is highly unlikely that you will have produced something that is as well tested, optimised and documented as the existing solution.
Secondly, as developers writing software which we intend to sell to users to pay the bills, we should be focused on the core features that define our product. It is these core features we should be pouring our energy and time into designing, building and testing. Developing alternatives to existing technology that is not in our core feature set is a waste of valuable time and energy and will not differentiate our product from that of our competitors.
We should instead be looking to leverage as many established technologies or components as possible when developing new systems as this lets us spend most of our time where it matters most on our core differentiating features.
Over the years at work I have tried various solutions to task management: the mental to-do list, the simple paper notebook, the electronic PDA or Smartphone, to-do software or combinations of the above. I have until recently not found a solution that lets me list my tasks and record what I actually do each day.
My solution is the humble Moleskine Weekly Notebook (below). As the name suggests the weekly notebook is a cunning combination of weekly diary (on the left page) and notebook (on the right page). This allows me to write my to-do list for the week on the notebook page and record what I do each day on the appropriate section of the diary page.
Having my work log and to-do list in the same physical entity has been a real break-through for me as it means I can track my progress towards my objectives and be able to account for where my time is spent each day. This has allowed me to analyse my working patterns and evaluate what is taking up time that could be better spent working on the tasks in my to-do list. Being able to record unexpected events that have taken up time e.g. build breaks or sickness has also proven very useful.
What I don’t use this notebook for is an actual appointment diary or strategic to-do list as I have found through experimentation that there is seldom sufficient space for such things. I have Microsoft Outlook which does appointment and calendar management and Evernote which does high level strategic tasks lists and note gathering.
I created the wallpaper below to remind myself about the implications of the Pareto Principle known commonly as the ’80-20′ rule that I mentioned in a previous post. Click the image for the original sized version.
Have you ever wondered why some projects develop functional prototypes almost overnight while other projects take forever to produce a working prototype? I think one of the major deciding factors in whether a project team will rapidly assemble a working product or not is if they are aiming for something that is perfect or ‘merely’ good enough.
“The perfect is the enemy of the good.” – Voltaire.
The pursuit of perfection is counter to the pursuit of a working product. To build the perfect product takes time: lots of time, more time than most companies can afford. To produce a good enough product takes significantly less time which increases the chances of actually getting it to market, making a profit and surviving long enough as a business to make a second improved iteration of the product.
“For many events, roughly 80% of the effects come from 20% of the causes.” – Pareto Principle.
According to the Pareto Principle (also known as the 80-20 rule) the first eighty percent of the output (effects) comes from only twenty percent of the work (causes). This eighty percent output is the ‘good enough’ product, therefore to produce the perfect product takes five times as long as the merely good enough.
The question you should ask is ‘Do we need perfection?’. I suspect unless you are programming medical, industrial or military equipment or software the answer is likely to be ‘No’.