In this chapter, Tompkins goes to Rome and gets in contact with a lawyer. They talk a bit about Tompkins’ old boss. Apparently, Tompkins really liked his old boss. His old boss arranged for Tompkins to meet with someone, Abdul Jamid. They start to talk about hunches. Hunches are prominent in this book, for example, Belinda deciding if she would hire someone. Hunches are generally in your head, but Abdul proposes a way to measure them and improve them. And it makes sense in some way, hunches are data inside you and there are algorithms to make a decision based on those hunches. By putting those hunches in a model, you would be able to improve your hunches. They mention a really clear example of why this is needed in the book that I really liked. If you and someone else feel unsure about something, how do you know who is more unsure? How do you measure that?
However, using the whole mechanism for modeling hunches may be overkill for just one, but the model is supposed to be used by dozens of them. To put this to the test, Abdul asks Tompkins some simple questions about a project with one hundred people in it that will take one year, will two hundred people complete it in six months? It may seem simple at first, but as they keep talking, this simple model evolves and includes many other factors, such as people quitting, the training period for newly hired people, etc.
Another huge factor that was brought up in their conversation is the size of projects. And it’s clearly stated that smaller teams are more efficient. A study done in 2005 revealed that a small team (less than 5 people) completed a project of 100,000 lines of code in 9.12 months, while a large team (more than 20 people) completed the same project in 8.92 months. This has a lot of implications. Sure, you actually complete the project faster with more people, but not by a lot. Not only was the difference small, but with a large team you have more people you need to pay. Paying 5 people for 9.12 months is way cheaper than paying 20 people for 8.92 months. However, this is not to say that big teams shouldn’t be used. The book also brings up that as a team works together for a long time, it will become more efficient and eventually become more than the sums of its parts.
The models won’t always be right, but they can be improved. Since you can now measure your hunches, as you manage more projects you will be able to improve the model with your new results.