Hackers and Painters
This book is a collection of essays by Paul Graham (of ‘Y Combinator’ fame) which can also be found on his website. I always find Paul’s essays to be very interesting and this collection is no different. It is a very thought provoking book, which makes it unexpectidily hard to pick out favorite essays from it. It covers a lot of topics software design, creation, running a business, strategy, managing, technology trends and programming languages.
I’d recommend it to anyone working in software development.
The Myths of Innovation
This entertaining book explains where ideas come from, why there is usually resistance to new ideas, dealing with the inventors dilema, how managers can encourage new ideas and problem finding (rather than ignoring problems). I found this book very refreshing as it helps dispel the myth that innovation is mostly about the idea, where as innovation is mostly about hard work and persistance in the face of resistance.
This book would be useful to anyone who creates new things for a living as it helps to explain why your great new idea is often met with disproportionate resistance from the establishment.
Stand on the shoulders of giants
Programmers have a strong desire to be the person who significantly and dramatically improves their system e.g. by increasing its performance with a new algorithm. However this desire often leads programmers to overlook how such improvements are commonly achieved. I believe the misconception is that these improvements are original works, when in fact the improvements are made by applying algorithms or design patterns that were previously unknown to the observer.
This mistaken belief can lead the unwary to attempt to create new solutions for established problems without first checking to see if the problem has been encountered before and if there is already has an established solution. It is easy to fall into this trap when ‘in the zone’ programming and to start solving a problem that has already been solved: how many linked lists implementations does the world really need?
Half of the solution to this wasted effort is education: there are many design pattern and algorithm books in existence and few reasons not to have read at least one of each genre. The other half of the solution is attitude, as programmers we need to make a conscious effort to be as lazy as possible: to reusing existing algorithms and design patterns as often as possible thus allowing us to get to the truly new problems…
“What Descartes did was a good step. You have added much several ways, and especially in taking the colours of thin plates into philosophical consideration. If I have seen a little further it is by standing on the shoulders of Giants.” - Isaac Newton.
Would Isaac Newton have made such a contribution to mathematics if he had first attempted to reinvent all of mathematics?
But I can write that in…
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.
Productivity Software Development: 80-20 Rule Software Development
by Daniel
1 comment
80-20 Rule Wallpaper
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.
Productivity Software Development: 80-20 Rule Software Development
by Daniel
1 comment
The perfect is the enemy of the good.
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’.
