In this episode I continue to look at professionalism in software development. I take the seventh 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 continuously ensure that others can cover for me, and that I can cover for them."
Or listen at:
Published: Wed, 30 Sep 2020 15:31:44 GMT
Links
Transcript
[00:00:35] Hello and welcome.
[00:00:38] In the last few episodes, I've been looking at Professionalism within Software Development. And I've been looking at it through the lens of the Programmer's Oath by "Uncle" Bob Martin, which I introduced in Episode 51.
[00:00:53] In this episode. I want to look at the seventh Oath:
"I promise that, to the best of my ability and judgement: I will continuously ensure that others can cover for me, and that I can cover for them"
[00:01:09] Let's remember, the software development is a team sport, it's not really about the individual or at least it shouldn't be if we're looking to have ROI over the long term.
[00:01:22] As a team, we need to be working together to support the organization's aims. As a team, we need to make sure whatever we are producing is not only correct for the organization and its customers. But also to ensure that it keeps running and it can be maintained over the course of its lifetime.
[00:01:45] We as a team should make sure that we are able to handle things like sickness, holidays, days off, or even if an individual was having an off day. We as a team shouldn't be putting the organization and the customer into a position where "no, we can't look at that because Bob isn't in", "no, there's no one can do that except for Jeff". That isn't really acceptable for something that could be potentially so critical to the organization or the customer.
[00:02:28] This is why we should be investing in the team rather than in individuals. We should be making sure that the teams are in a position where they can share knowledge of how all the various systems work, how they can be looked after, how they can be maintained. If there's a problem, what do we do about it?
[00:02:49] Now, some people turn around and say "OK, just document it". That isn't really practical. It's very difficult to get a good level of understanding of a system purely from documentation. I write quite a considerable amount of documentation. I also read quite a considerable amount of documentation. And I know very well that without some understanding of what the system does, that documentation is purely a starting point.
[00:03:16] It really does help to have that real understanding of what it was the system was designed to do as being part of the team that built it.
[00:03:28] And I don't think this is necessarily just the case of sharing within the individuals technical discipline. Potentially, I'm working with other people in the team that may have skills that I don't have, I should have some sort of idea of what those skills are. I should have some sort of idea that if they aren't there, can I do something on their behalf? The more we have to rely on a specific individual, the more the team struggle to look after the software and maintain it for the organization and the end user.
[00:04:03] It really is critical for us to have a level of professionalism, to be confident that we can make changes, we can support the system based on whoever is in at the time. Two activities that are very good for this are pair programming and mob programming, I introduced these in Episode 23 and 24 respectively. Pair programming is the act of two people sitting at the same keyboard, same mouse, same screen developing the system. One acts as driver, one acts as navigator. As the pair work through their assigned task, because they're working together, you get the value of being able to share ideas straight away. You get the value of never having, or at least greatly reducing, A time when a developer is sitting their stock.
[00:05:02] They're not grinding their wheels so much because there's two of them. They can talk things through. They can work the problem through.
[00:05:08] Pair Programming helps you deliver better quality and better understanding across the team.
[00:05:15] Mob Programming is a stage on from that, we're actually more than two people and I've run this with teams of five or six, which for me was an excellent opportunity for people to learn how the system worked. And it worked very well for a system we were trying to increase the knowledge on. So certainly worth looking at that to enable the wider team to understand how the system works and to allow them to be in a position when they can cover for it.
[00:05:48] So why doesn't this happen? Well, there's a number of reasons why we don't get to understand each other's work. There's that resource utilization I talked about in other episodes. Where we think to get the best ROI from a developer, then they should be heads down on their problem. We should carve out work so that their day is 100 percent occupied with work. We struggle to see the longer term benefit of having them work as part of a team.
[00:06:21] Think about acting as part of a pair or a mop, your immediate reaction may be "Why am I paying two people in pair programming and potentially five or six people in my program to do the work of one?"
[00:06:36] But that isn't the case.
[00:06:39] Because, of course, what we're not talking about here is just utilizing that individual developer, because you're talking about a much better level of quality, a much better understanding, you're actually getting benefit from. The team understanding it, the team producing a better level of quality and actually producing better ROI over the lifetime of the product rather than just focusing on payback of an individual developers time.
[00:07:09] We also have a tendency to create team silos by technical discipline. So we might have developers, we might have testers, we might have database developers, we may have frontend developers. These may be completely separate teams. And as such, we don't like to share knowledge across those silos.
[00:07:29] Now, this is bad for software development. It's bad for ROI because you get into a situation where so much time is spent trying to transfer knowledge between those groups that you're paying a huge overhead just for any level of conversation. By having the team aware of how to do all of these things, not only are you gaining the benefit of not having to go outside the team to get work done, which is an expensive activity, you're also gaining that ability where they can cover for each other in the event of, as I say, holidays, illness or just off days.
[00:08:12] The other pushback you'll get is from the individual developers themselves, some will come back and simply say "It's not my job, this is my job. I have a very narrow focus. This is what I do now."
[00:08:24] Unfortunately, in this day and age and in modern development, I don't think that is a particularly helpful response. There are developers who are exceptionally specialized, as in any industry, but what we're looking for here is a level professionalism of our team that they're cross disciplined enough to be able to pick up other people's activities.
[00:08:49] Now, you might need a very specialist developer for very specialized task. For a very niche part of what you're trying to achieve. Now, that's where you normally go outside of the team and maybe bring in an outside resource, maybe a contractor, maybe someone else from another part of the organization. They should be coming in and imparting that knowledge into the team. It shouldn't be a case that you have someone in the team whose sole responsibility is "This is mine. I just do this" - Because that's not a team - that is then a collection of individuals.
[00:09:25] In the next episode, I want to move on to the eighth oath:
"I Promise that, to the best of my ability and judgement: I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty."
[00:09:46] Thank you very much for listening, and I look forward to speaking to you again next week.