You will come across several situations over the years in IT where some knowledge about some general laws would help with planning and decision making. Estimation is one of the most difficult tasks facing software designers, developers and testers. In some cases, you may as well ask how long is a piece of string?
This is where Hofstadter's Law is relevant. If you are planning a task it will always take longer than you expected. The planning fallacy is a very important issue that as a software planner you need to be aware of. This is why we have contingency. We have to be aware that there are unknown unknowns, as Donald Rumsfeld pointed out.
To get an understanding of Hofstadter’s law in the context of software development it is good to take an overall view of planning methods and development methods. For project success, iterative/agile development has one of the highest success rates. This is because you plan for what you see ahead of you, not for what you don’t know.
It is good that you deal with each problem as it presents itself and do not waste time planning for the unexpected that may never happen. This is what often occurs when you use the waterfall approach. Estimation is easier when you build in small attainable goals, adjust project scope to deal with issues as they arrive and build on success.
This brings us to the next law, Brooks Law. The law highlights that ‘adding additional people late in a software project makes it later’. This happens when you are nearing the end of a project. Let us assume that approximately two-thirds of estimated time is completed, when it seems like your team won’t meet your deadline.
It occurs to you or someone else,usually senior management, that more people or inexperienced testers on the project would do the trick. This is where you need to know about Fred Brook’s Law. He wrote a book called the mythical man month. Steve Job’s explain’s it quickly. Just bear in mind that there are exceptions to every rule.
Think of Brook’s law as a good starting point. You can mitigate against the pitfalls, rather than being ignorant of the law and just throwing people at a problem and expecting a result. As a test lead beware of managers bearing gifts, i.e. extra staff, that later turns out to be more trouble than it was worth.
Finally be aware of the Pareto principle, also known as the 80-20 rule. This is where 80% of the effects come from 20% of the causes. This is particularly useful in software risk testing. Remember when you are developing or testing that the most important part of the work will be in twenty percent of functionality. Focus on the really important stuff and the rest will get sorted in due time. There are many other laws out there. If you have any favourites let me know.