Recently, I finished reading the book "How Big Things Get Done". In this book, author tries to review why complex projects often fail (take more time than expected, go over budget) and how to mitigate these risks. I want to share some insights with you.
Let's start from ☢️ nuclear energy (trust me, we will get back to Software Engineering). Many of the nuclear power plant projects fail to comply with the initial estimates. The mean cost overrun is 120%, but actually, most of the projects fail more than that. The overrun is not distributed like a bell (normal distribution), this distribution has a fat tail, meaning that if you hit overrun, then it's more likely that your one will be more than the mean one. The mean overrun of the projects in tail is 204%. With nuclear power plants, we are talking about billions of dollars of overrun. Sounds important, isn't it?
☀️ There is another category of big and complex projects — solar power plants. What are their numbers? The mean cost overrun is 1% and mean tail projects overrun is 50%. Better, isn't it?
Why does it happen this way? The answer brings us back to the Software Engineering — modularity. Nuclear power stations are definitely a cool thing, but they are very unique. Countries and governments have not enough experience in building such, and they are not that modular (even if they are, the modules are very complex themselves). While with the solar station, you have modules — solar panels. You "just" need to put them together and connect to the chain.
With this kind of module, you can iterate faster, improve your module faster, make it cheaper, and make it more maintainable. If the panel fails? Replace it with the other one, which was produced in a factory. Unfortunately, you can not produce nuclear power plant in a factory.
Solar stations have their Lego bricks — solar panels; nuclear power stations do not. In the first case, we build a complex thing from many simple things; in the second, we build complex thing from many different complex things. The chance of the failure is higher.
We can apply this to our regular Software Engineering practices. What are our Lego bricks? I give you an example:
* skeleton project. Whenever we want to start a new project, we do not start it from the scratch, we copy our skeleton.
* unified CI. Do you need to have custom
.gitlab-ci.yml in every project? No, if your CI is unified, it's easier to integrate and support* unified unit and integration tests setup
*
API standards — let's define and document them* patterns of service to service communication
* else?
When you have these Lego bricks it allows you to combine them with low risk and attach your unique stuff on top — business logic.
▪️As Senior+ SE it's our task to think from the "lego brick" perspective. Which bricks do we already have in our team? Which bricks are we missing? This will make your delivery consistent and maintainable.
💬 Please share which other examples of Lego bricks in SE come to your mind.