During September, I'm running a short survey to understand UK Executive's attitudes to custom software development. Please take the time and have your say at: https://software-survey.red-folder.com/ In this episode I continue to look at professionalism in software development. I take the fourth oath from the Programmer's Oath by Uncle Bob Martin, introduced in episode #51, to explore further: "I Promise that, to the best of my ability and judgement: I will make frequent, small, releases so that I do not impede the progress of others."
Or listen at:
Published: Wed, 09 Sep 2020 15:57:41 GMT
Links
Transcript
[00:00:35] Hello and welcome. In this episode, I'm going to continue the conversation on professionalism within software development. In Episode 51, introduced the Programmer's Oath by Uncle Bob Martin. And since then, I've been looking at an individual Oath per episode. In this episode, I'll be looking at:.
"I Promise that, to the best of my ability and judgement: I will make frequent, small, releases so that I do not impede the progress of others."
[00:01:10] For me, there is a lot of crossover with the first Oath "I will not produce harmful code."
[00:01:17] In that episode, we talked about how certain actions a software developer can cause harm to the end customer, the team and the organization. And this seems very much along that same line. When we're talking about impeding others, we're probably predominantly talking about other developers. We're predominantly talking about stopping them from being able to do their work. So again, harming their ability to actually work and thus by knock on effect, harming the ability for the organization to be able to get a good return on investment. And ultimately harming the end customer.
[00:01:59] This talks about a developer potentially hogging the system. Potentially making it difficult for others to work on by effectively taking away from others while they're working on it. And especially if that's a prolonged period, that becomes very difficult for a team to be able to work on the same thing at the same time. And this comes down to a level of almost selfishness in terms of how I'm going to take the system and do what I want to do.
[00:02:27] Whereas a team obviously then struggle to continue to do what they need to do.
[00:02:33] One of the obvious dangers for me in this is a term called "Merge Hell". "Merge Hell" comes from the exercise of having to take two different pieces of work on the same system and merge them together.
[00:02:50] Take, for example, if you and someone else are working independently on writing a contract or a sales proposal. Now imagine that you work independently. And you come back together maybe weeks or months later. When you then try to combine the efforts of those two documents trying to work out which bits should be from which contributor becomes quite difficult, especially if you've both worked on similar parts, if you've both worked on elements of the NDA, for example.
[00:03:24] Which one is the better version to use? Do you need to actually merge the two? And this is very common in software development.
[00:03:32] If you have a team working all on the same software product, if they work as individuals and then come to merge their changes together, it can be very common to get into a position where it's difficult to know which piece of code to take priority, whose work is right. And indeed, is there a right? Is it actually that both pieces of work or multiple pieces of work even need to be looked at and worked back in together to actually create something that is greater than the sum of the parts.
[00:04:04] And this can get very difficult. And it becomes more difficult based on two things. One, how big the changes, which can also equate to how long the changes have not been merged together and how many different contributors are involved.
[00:04:26] Imagine, for example, that we have three separate contributors. They all go away at the beginning of the month, they all go off and do their own thing for a full month. They work solidly on what they're doing for a month. At the end of the month, they come back again and then they try to merge all the changes back together. And this is where "Merge Hell" happens.
[00:04:50] You so often find that they've been working on the same areas, maybe not completely, but enough to overlap, and it's then the exercise of trying to decide what's right, what's correct, and that produces a lot of work. And that can be very then expensive to have to redo those changes, not only have you invested in them actually making the change in the first place, you then are having to invest again for them to be able to marry the changes together.
[00:05:21] I'm reminded of a story once where a software developer was telling me that they were working on version two of a product. Version one was still being written by another team, and the team working on version two actually were quite worried about this. They were unsure as to what the outcome of the version one software being developed by another team would actually look like. But they were convinced and told to carry on. A number of months later, after they've been working hard and ready to make their changes for version two, they went back to the version one, which was then complete and realized that version one was nothing like how they'd expected it to be.
[00:06:09] They've been told one thing during conversation, and they based all of their work on that, only to find out that version one actually had to be different because of various reasons. This resulted in the version two work having to be effectively scrapped and redone.
[00:06:28] And this is why we talk about trying to keep those changes small, we talk about making those releases frequent so that we're not in that position where we're having to go back over so much work to actually try and get a stable base point.
[00:06:48] Let's talk about the benefits - and the key here is the word "small". If you've heard me talk previously about minimum viable product, I advise working in very small increments, making a very small change and getting out to market quickly, allowing us to test hypotheses very, very quickly.
[00:07:12] It's an experimental nature. So keeping it small for me is what you want to do anyway.
[00:07:18] It makes it easier to test if you're only making a small change. The system doesn't take long for you to validate it, which means you've got better quality. You have lower risk to the organization because you're making a small change, you're not making monumental changes and shift in structure that could potentially put greater risk on how your customers use the software, how your organization uses the software, and how you derive benefit.
[00:07:47] And of course, as I say, that's quicker to market. And that allows us to fail faster, it allows us to learn quicker and it allows us to achieve better outcomes.
[00:07:59] So for me, small is good because we have to look at it through the lens of it being an experiment.
[00:08:05] We don't know the change we are making is going to be positive. We think it might be. We think that this change is going to be good for us. We think the customer is going to love it. We think it's going to make money for the organization
[00:08:17] Whatever it is we think may happen, we do not know that that is true until we have tested it. So the ability to have nice, small, frequent releases means we are in a much better place to know if that's true.
[00:08:35] One of the side effects of being that I have a small, frequent releases, of course, is we know that we can actually release the software.
[00:08:44] So often I find that big pieces of software haven't been released for months, potentially even years, so when we want to make a change to it, when we release it, it's a major event that has to be a huge amount of planning. That has to be a huge amount of ceremony. There has to be a huge amount of risk accepted in doing it.
[00:09:10] This is where we end up having releases taking all night or over the weekend. Maybe taking the service they're actually updating down Maybe we're updating a customer facing website that needs to be taken down while we do these changes n - because they're large.
[00:09:26] Whereas if they're small and we're doing them frequently, we develop the ability, the processes, the capability of being able to do it quickly, being able to do it with minimal impact. Ideally, getting down to the point where there is so little risk, there is so little no small impact to the end customer, that we can be doing this multiple times a day. So for me. The benefits definitely there.
[00:09:51] This comes back into things such as DevOps which I introduced previously - which allows us to be able to experiment quickly with small changes, get them into the hands of our customers quicker to get that feedback.
[00:10:07] In the next episode, I want to look at the fifth Oath:.
"I Promise that, to the best of my ability and judgement: I will fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them."
[00:10:25] Thank you for listening. And I look forward to speaking to you again next week.