It is generally regarded that there are three primary properties of a software product: cost of development, performance (speed/memory etc) and software quality. It is believed that you can only ever obtain two of these properties at the cost of the remaining property e.g, you can have high performance and high quality but it won’t [...]
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 [...]
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 [...]
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 [...]
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 [...]