This is the second article in a series where we cover the book Software Engineering at Google by Titus Winters, Tom Manshreck, and Hyrum Wright. 📕 We will go over various aspects of software engineering as a process, including the importance of communication, iteration and continuous learning, well-thought-out documentation, robust testing, and many more.
In this article, we cover one of the key elements that take the act of programming into the domain of software engineering - iteration.
What drives iteration
As we said in the first part, software engineering is programming over time. What essentially makes up software engineering is the act of programming repeated over and over again, making the piece of software evolve and change, either on the functionality or the implementation level. We have a fancy name for that. It is iteration. ♻️
For inherently data-driven engineers, we often want data to be the only deciding factor to perform another iteration. That means data collected straight from the product (for example through analytics or logs), from user feedback, or perhaps market research. The book points out, however, that this is indeed a good start but in reality, most decisions are based on a mix of data, assumption, precedent, and argument. It's best when objective data makes up the majority of those inputs but it can rarely be all of them.
Being data-driven over time implies also the need to change directions when the data changes (or when the assumptions are dispelled). Mistakes or revisited plans are inevitable. Treat them just as a part of the journey. 🛤️
The point of iteration is...
...starting antoher iteration. The faster you can get the results of the iteration in front of the prospective users and collect relevant feedback, the better. It means you can correct the course, avoiding problems and wrong assumptions. That's valuable across many levels - from a single increment of code that you put up for review, through features you're team is working on, all the way to entire products or suites of products.
If you spend all of your time working alone on a feature you are increasing the risk of unnecessary failure. Even though software development is deeply intellectual work that can require deep concentration and a long time you must play that off against the value of collaboration and review.
If you keep your great idea hidden from the world and refuse to show it to anyone until the implementation is polished you're taking a huge gamble. It's easy to make fundamental design mistakes early on. You risk inventing wheels. Having the feedback loop shortened is almost always beneficial. 🏆
Conclusion
That's it! We now have a solid understanding of what iteration is and why are we doing it in the first place. Here's a short summary of things we went through:
iteration in the context of software engineering
drivers of iteration in software projects
the importance of making iterations as short as possible
Next up, we will briefly touch on communication, which is often a bottleneck for a lot of engineering teams. See you! 👋
If you liked the article or you have a question, feel free to reach out to me on Twitter‚ or add a comment below!
Further reading and references
The original Twitter thread with notes from the book
Link to purchasing the book
Photo by Jake Blucker on Unsplash