In this episode I continue to look at professionalism in software development. I take the second 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: The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate."
Or listen at:
Published: Wed, 26 Aug 2020 16:12:05 GMT
Links
Transcript
[00:00:34] Hello and welcome. In this episode, I want to continue looking at professionalism within software development. We'll continue to look at the Programmers Oath by Uncle Bob Martin as a means of doing that.
[00:00:50] In Episode 51, I introduced the Programmers Oath. In the last episode, I looked at the first of those oaths and in this episode I want to look at the second oath.
"I Promise that, to the best of my ability and judgement: The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate."
[00:01:21] So what do you mean by best work?
[00:01:25] Well, ideally, this is the work that needs, to be blunt, our best work, it needs to be of a quality and standard that we are happy with. And again, obviously, we're talking about professionalism here, so you have to arrive at what you believe that standard is.
[00:01:41] Possibly if we look at the factors that affect that standard, it may help us to understand what we're talking about. For me, a software developer to get their best level of quality and standard of work, they have to have a good self realization of themselves, a good self-awareness. They need to be aware if they're not bringing their "A game" to their work.
[00:02:09] Now, this might be because they're tired on any given day, they're stressed by things in work or outside work, personal life, money problems, and obviously during the Covid-19 crisis, currently, any number of worries could be causing somebody to struggle to provide their best.
[00:02:30] And it does come down to that self-awareness for an individual to understand I'm not going to be able to do my best today. Whatever it is that's affecting them, and it may be illness, it may be tiredness, it may be stress, as I've said. That they know they're going to turn into work and they know they're not going to do their best work. And again, that comes down to self-awareness.
[00:02:53] If we use myself as an example. I actually feel very tired. I've had two nights of heavily disturbed sleep due to weather, temperature and storms. Now I know I'm probably not going to do my best work today. I know that some work I've been doing this morning, I've had to do extra tests. I've had to do extra validations to make sure that the work is of a standard I am happy with. Maybe if I've been properly rested, I wouldn't need to do that.
[00:03:27] So potentially we've actually incurred extra cost to do the work because I myself am not in the best place to do my best work. Now I can counter that by putting alternative steps in place to protect the organization, to protect my team and protect myself. In this case, extra testing. But there has to be an acknowledgement that once you've reached that self realization that you're not going to do your best work, it has to lead to a level of professionalism.
[00:04:00] Now, that professionalism could be simply turning around and saying no.
[00:04:06] So when being asked to do something, especially if it's urgent, especially critical, especially if it's something that's high pressure, if you're not in an ability to do the best you work, the correct answer may very well be no.
[00:04:19] Now, that could be a hard truth for both the developer and the line manager to accept. I suspect many line managers won't be happy with a developer turning up, going "I'm afraid I can't do that urgent task. You wanted me to do today. My head's not in the game. Instead, I'm going to go for a walk in the park and clear my head".
[00:04:42] Now, that actually may be the most professional and correct answer that software developer can give, and the correct and professional answer for the line manager is to endorse that and to actually encourage the software developer to step away. But that's probably rare. It is quite a difficult message to give and it's quite a different message to hear. And it takes a level of courage on both part to be confident that they can work in that way. To be confident that it is professional to actually turn around and say "no, if I do this now, I will actually be causing problems".
[00:05:20] And this obviously comes down to choices when we talk about best of my ability and judgment. We have to do what we believe is correct.
[00:05:31] And there is never going to be hard and fast rules on this. This comes down to time and experience. It comes down to how that individual and have the wider team cope with it. So, for example, I have talked about myself, I know that this morning I was tired than I would normally be. I know that there's a good chance I'll make more mistakes because of that. As such, I cope with that by making more tests, validating more often.
[00:06:01] Yes, the work will take longer to produce, but it's important I keep a level of quality above trying to just deliver something quickly that actually will have problems and cause harm later.
[00:06:16] Uncle Bob Martin talks about these choices similar way to the Boy Scout principle of always making sure that you leave a campsite better than you found it, always making improvements, not letting it degrade.
[00:06:31] I remember using a similar principle once in a shared kitchen. It was a kitchen used by probably somewhere between 30 and 40 staff. It's a very small kitchen and it was one that very quickly, if people weren't paying attention, could very quickly get into a mess.
[00:06:46] There be dishes, there'll be cups of tea bowls, there'd be spoons just left everywhere, as well as food strewn across the surface. Really not very nice to even walk into, let alone use. So trying to instill a level of boy scout principle with that kitchen of "look, how do you want to see it when you walk into it, make sure you leave it cleaner, better than than you found it". All the time making improvements. All the time, making it seem like you would be happy to use.
[00:07:18] It's the same principle of broken windows in an office block. You've heard the stories of how an office, once it develops, one broken window, will quickly gather more because people think that the building just isn't maintained. Nobody cared. As such, it's open season to continue to degrade it.
[00:07:41] And a lot of these choices come back to the technical debt conversation I introduced in Episode 16. It's that principle of looking at where you're incurring debt over the longer period. And in cases here where you're making an active choice potentially to maybe work while tired, maybe work while your mind isn't on the game, that you could be potentially causing harm later on and cost each one expensive mistakes that potentially can be with your system for many, many years.
[00:08:16] It's not uncommon to find problems that are long held within a system because people don't really think about it or understand the right way of going about making sure that it wasn't introduced in the first place and then secondly wasn't removed when it was found. Again, it goes back to that idea of I'm too tired to do this, I'm going to do this shortcut way. And then somebody walking in after you like that kitchen and going "I'm not clearing that mess up. I didn't make it. I'm just going to do what I need to do." And as such, it accumulates.
[00:08:48] And of course, that accumulation is important if problems are allowed to accumulate. Then we get into a position where we cause harm to everybody that's using the software, reverting back to that first oath in the Programmers Oath, we cause harm to the business because it costs more to maintain and manage. As time goes on, we cause harm to our team because it makes it difficult to work with the software, makes it difficult to add stuff. It makes it difficult to do anything again. Going back to that kitchen, it physically disgusts people to go into that room to use the kitchen because it's such a mess. And the same is true of software if it gets to such a mess. I've known people walk away from a system rather than develop on it because it's difficult to understand or even disgust them in terms of just how poor it is.
[00:09:45] And of course, ultimately, our end customer, our end customer can be being harmed by poor software, by our inability to adapt and move with them in the market. So it definitely comes back to that first Oath of:.
"I Promise that, to the best of my ability and judgement: I will not produce harmful code."
[00:10:12] In the next episode, I want to move on to the third oath:.
"I Promise that, to the best of my ability and judgement: I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should."
[00:10:32] Thank you for listening. And I look forward to speaking to you again next week.