Optimisation effort Vs. Performance Gain
This may seem strange but in my experience it is true that the first few optimisation efforts on any un-optimised system tend to yeild high returns for low effort e.g, tweaking some compiler or linker settings in a few minutes. Further medium term efforts tend to suffer from diminishing returns e.g, rewriting critical sections in assembler over a few days for a few percent improvment. Finally large scale optimisations e.g. refactoring entire sub-systems over a week or more tends to yeild significant benefits.
Work Blocks in Action
In my previous post I talked about work blocks as a way to prevent meeting requests from fragmenting your working day to such an extent that they prevent flow and impair your ability to get stuff done. Above is a graphical example of roughly how my work blocks are arranged in my calender: I’ve two mornings and two afternoons blocked off giving me two half days and one whole day where I know at least half the day is mine.
Effectiveness Vs Communication Load
As the above graph demonstrates, there is a practical limit on team size before the communications load required to keep team members in synchronisation begins to significantly reduce individual team members performance. The usual method for combating this trend is to partition large teams up into smaller teams to reduce the communication overhead per individual.
Source ‘Agile Software Development’ by Alistair Cockburn page 160.
Bugs / Source Code
This at least is how it always feels: a mystical 10% of the code base causing 90% of the reported bugs. This makes it very important to identify the 10% of the code that is causing the bugs and then resolve those issues as a matter of priority. Wasting effort on the other 90% of the code base until the problem 10% is resolved will not make a noticible improvement in the product quality.
Programming Software Development: Testing Visualisation
by Daniel
leave a comment
The cost of bug fixing
The following graph is why I think the cost of additional design reviews and additional testing during implementation (e.g, unit testing and code reviews) is justified, because it is still far cheaper than fixing the issues later during testing or after product release (maintenance).
Source data from IBM Research.
