Book: The Nature of Software Development. Ron Jeffries

The Nature of Software Development. Ron Jeffries

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 that 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 actually 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 originally 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 started. 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 needed, but the planning itself invoke 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 a team can start work with a clearer understanding, what is expected at least from part of their job on the task.

2. Choose next task based on what task can bring currently 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 remains applicable and useful in everyday life and vice versa. In terms of software development, I am still thinking about this statement, as I think 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 big resources, and can be seen as it primary will allow shipping software, that contain fewer regression bugs, but I think that often unseen value in such improvements, is that good coverage of the functionality by the automation end-to-end 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 development, of future features etc. 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 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 definitely 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 has as a requirements for the project to be accepted, and then there was second way of opinions, which where 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 important 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 fine 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 exactly to the slower delivery, they just lead to more unpredictable future, and more unpredictable time needed for creating new features.

And what are your thoughts about this statements?

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Olena Sovyn
Front-end developer (London, UK). I ❤ React, Redux, lodash, React Storybook, and functional programming overall. Always open to learn something new

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Spelling error report

The following text will be sent to our editors: