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 fifth 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 fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them."
Or listen at:
Published: Wed, 16 Sep 2020 16:04:25 GMT
Links
Transcript
[00:00:34] Hello and welcome. In the last few episodes, I've been looking at Professionalism within Software Development. I've been doing this through the lens of the Programmer's Oath by "Uncle" Bob Martin. In this episode, I want to look at the 5th 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:01:00] Now, to me, there's a lot of similarity with this over with the second oath
"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:18] For me, as I say, there's a lot of similarity, both of them are talking about quality. Both of them are talking about avoiding things like technical debt. Both of them are talking about that same subject of avoiding causing harm, harm to the end user, harm to the team, harm to the organization.
[00:01:38] So harm to the end user in terms of trying to avoid bugs, making it better, making sure that it is better for how the customer needs to use it. Better for the team so that it's easier to work with, easy to test, better to make quality. And for the organization, easier to maintain and better to produce a quality product which produces a good ROI.
[00:02:02] But improving that creation can take a level of bravery. We can expect pushback sometimes, and I've talked about this in previous episodes where you get pushback because what you're being asked to do or isn't what you think is necessarily the right thing to improve your creation.
[00:02:22] Potentially, you're looking at improving the quality of it, potentially you're looking at making it better to maintain and provide a pathway over the longer term. But is that what you're being paid for and if.
[00:02:35] Unfortunately, you're struggling to get that across to the people that are paying your wages. That takes a hell of a lot of bravery to be able to push that professionalism forwards. It comes back to the heart of why the program itself is looking at that level of professionalism in terms of being able to turn around and say, "no, we need to be able to do these things to have a professional level".
[00:03:01] But it does, as I say, come back to that mindset of the people that are paying for that product, sometimes assume that there's that level there. Why would they be paying for you to be making your creation better? Surely they paid a premium price; for it to be right in the first place.
[00:03:18] So sometimes the message gets lost in terms that the people are actually funding this, are actually misunderstanding what is being proposed. They believe you're giving them an either or situation, at which point it becomes a "well, does this sound like I need to spend this money?"
[00:03:34] And again, I come back almost to the testing one I've talked about in the last episode about proof. When you're talking about a premium product, you would expect to have a level of proof that it does what it says on the tin.
[00:03:49] So why should we always be trying to improve our product? Why should we be trying to avoid degradation? By nature, systems will degrade over time, they will become less perform, and they they'll be filled with log files, they will be filled with extraneous data. The systems they work on will become older, maybe need patching.
[00:04:12] The very nature of time means that all of our systems will degrade if we don't touch them.
[00:04:19] It needs that constant level of improvement, it needs that constant maintenance, even if it's only small, just to make sure that everything is running optimally.
[00:04:29] If left to them, left to itself, the system will continue degrade over time, and I've seen this in systems that haven't been touched for years. The initial work just to maintain it may have been maybe five, 10 minutes a month. But because it hasn't been touched for so long, nobody really knows how it even works anymore, let alone what they need to do to return it back to a good state.
[00:04:54] And I'm repeating some things here from Episode 53, things like the Boy Scout principle, the shared kitchen example I provided, and talking about the building with broken windows. You find that a building that has a broken window, that hasn't been looked after, hasn't been addressed, it soon collects more broken windows. Because as soon as somebody sees a broken window in a building, it's believed, well, it's not being maintained, it's not being looked after. It doesn't matter. And it's the same principle here, if you don't maintain it, nobody cares about it, nobody believes it's important that it needs to be looked after, even if it is potentially one of your most important systems. But if it's not being maintained and actively worked on, then it soon degrades. It soon becomes that building with all the broken windows in it.
[00:05:48] We're also talking about craftsmanship here in terms of being able to learn and improve and make your system better based on what you know now. Well, I knew five years ago it's nothing compared to what I know now, what I know in five years time is much greater than I know now.
[00:06:06] As you learn, as you grow, especially in software development, you learn better ways of doing things. You learn better procedures, better techniques. You understand the problem better. As such, you can constantly be improving that system. You can constantly improving and making it better.
[00:06:24] Now that maybe it fits the user's needs better. Maybe there are certain buttons that are in the wrong place and they are difficult for a user to understand where to look to find them. Maybe it's improving the speed because you've built what looks to be a really great website, but for mobile use over slow data connections, maybe they struggle.
[00:06:45] It could be any number of things that you learn as you go through and you should be looking for those abilities to improve that creation over that time.
[00:06:55] Some systems, obviously will be too small and you might not need to, but most systems have a long shelf life and actually need to have this to maintain the level of ROI.
[00:07:07] And there are some side effects from being able to maintain these systems. So often I will find systems that haven't been touched for six, 12, 24 months even, but they're core to how the business works.
[00:07:20] "Oh they've always worked. They're fine."
[00:07:22] But I imagine you need to make a change to it. How confident are you then? That you can add that change without disrupting standard behavior. How confident are you that you know how to test all the previous work that was there? How confident are you that you can have a developer come in, make the change and it be a positive effect rather than causing outage and downtime?
[00:07:47] And this is one of the side effects of being able to continuously improve that creation. You're in a position then that you know, you've released it last week because you made a small change to it. Now, when you need to do something in emergency, you know how to release it.
[00:08:00] You know where the code is. You know how to make the change. Everybody has that muscle memory.
[00:08:09] And I think it also talks about not being scared to start with basics. So you might be building a system and I've seen this so many times when people want a system built they will produce a laundry list of features. It will be everything, including the kitchen sink, most of the time. A lot of that is not needed most of the time.
[00:08:28] Most of the key features within a software product or website are following the 80-20 rule, only 20 percent of the features drive 80 percent of the usage, the other 80 percent do they need to be there? Are they actually covering the value they need?
[00:08:47] If we can think in that way, we get back to that minimum viable product route where we can accept "Let's start with what we need. Let's get that out there."
[00:08:54] Let's see if that validates our understanding is that producing value to the customer then lets fearlessly and relentlessly improve on that by adding extra to it, adding the extra things that our customers are crying out for, adding the extra things that we can prove produce value for us and for our customer.
[00:09:16] In the next episode, I want to look at the sixth oath:.
"I Promise that, to the best of my ability and judgement: I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity."
[00:09:35] Thank you for listening and I look forward to speaking to you again next week.
[00:09:44] This podcast has been hosted by me, Mark Taylor, it has been produced by Red Folder Consultancy Ltd, a consultancy that can help you achieve better return on your software development investment. You can contact them or sign up to the mailing list at Red IFN folder dot com, or you can reach out to me on Twitter at red folder. Mark, if you're getting value from this series, please tell a friend and help me grow my audience.