This book was suggested in our company as one that is pretty short but contains the main concepts about how software should be created. And after reading it by myself, I dare say, that is quite an inspiring short reading, even though it is mainly covering popular nowadays project management ideas – Agile & Scrum.
The main take away for me form this book was a mix of what I have read, and thoughts to which this book has inspired me. Here are a few of them, that provoke some “aha!” moments in my head:
1. Plans are useless, but planning is indispensable
Even though that this phrase initially belongs to General Eisenhower, I have first seen it in this book, and find it quite useful in terms of concepts through which about what is happening in your team, when the project is starting or has already begun. As from time to time it can be tempted in the stage when the project hasn’t been started yet, to skip proper planning with an excuse, that in any case, as our previous experience is telling us, our plan will be or wrong, or incomplete, or not needed. With reading this phrase, I understood, that even though the result of this can be not required, but the planning itself invokes many vital processes for the project overall in a quite early stage. It will allow to more precisely to look at any unknowns that remain in need requested functionality, run very early some pre-mortem session (even if they are happening only in someone head, and not an official part of the planning process), identify measurable and doable tasks so that a team can start work with a clearer understanding, what is expected at least from part of their job on the task.
2. Choose the next task based on what task can bring the biggest value
I think that this sum up one of the other books that I have read at the beginning of this year – “Essentialism: The Disciplined Pursuit of Less. Greg McKeown”. And I found it quite fascinating that some of the concepts that are true for project managing in a BIG world also remain applicable and useful in everyday life and vice versa. In terms of software development, I am still thinking about this statement, because I feel it often misused for seeing this biggest value only in the features, that can be delivered to end customers, but I have a feeling, that in any project there are numerous tasks, that can not only provide some values, that is measurable, but also empower people inside company (unblock some hidden potential). In speaking globally, for example, adding QA automation testing can require significant resources. It can be seen as it primary will allow shipping software, that contains fewer regression bugs. Still, I think that often unseen value in such improvements, is that good coverage of the functionality by the end-to-end automation tests will unblock for developer do much deeper refactoring, fight more complex tech debt, in the same time knowing that they can safely ship this changes, as they have end-to-end test coverage good, and will not need abnormous manual QA resources to be able to ship this changes. And this refactoring can lead to more stable code in the future features, or easier future features development. So it is actually accumulating effect, that I think is one of the main types of the values, that we can look for when thinking about the software – how changing something can lead or unblock to massive improvements in the future.
3. Delaying adding tests, fixing bugs, fighting tech debt does not always make software development take longer, but it makes it more unpredictable in terms of time estimations
I do not know have you been at that time in the industry already, but I quite can recall in my memory times, when at first TDD become very popular, and nearly everyone was using them and had as a requirements for the project to be accepted, and then there was second way of opinions, which were that writing unit tests are waste of time as there are tons of project that are superbly fine without following TDD approach. Even though this book is on the side that sees tests as an essential part of the project, I have learned something different from the section that was dedicated to testing. I have learned that, yeap, we can be okay without testing, for now, we can even deliver future features without having unit testing, and be fine there, and even deliver them faster, than teams that are doing TDD or ADD (acceptance driven development), but the point is, that the fact that we deliver faster, is just one of the possible outcomes of our project, and if we have fewer tests probability of such an outcome decrease. Because fewer tests are not leading precisely to the slower delivery, they lead to a more unpredictable future and more unpredictable time needed for creating new features.
And what are your thoughts about these statements?
If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.
