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 sixth 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 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."
Or listen at:
Published: Wed, 23 Sep 2020 15:55:06 GMT
Links
Transcript
[00:00:34] Hello and welcome.
[00:00:37] In this episode, I'll continue looking at Professionalism within Software Development. And I'll continue to look at it through the lens of the Programmer's Oath by "Uncle" Bob Martin. In this 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:01:06] So let's talk about productivity for a second. What is productivity? There's a couple of definitions if you look it up on the Internet, first definition:
"the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input."
[00:01:27] Or:
"the state or quality of being productive"
[00:01:34] Now, I see a lot of dangers in productivity, especially if you look at that first definition and that first definition. It talks about measurements of ratios between input versus output. Often what I find is people are actually looking at productivity about utilization. So when you look in an expensive resource such as a developer, people think of productivity in that sense as can I get 100 percent of that development use? Can I make sure all of their time is taken up on what is believed to be productive work?
[00:02:09] They're focusing on the utility of that individual rather than necessarily the value of the output.
[00:02:18] I much prefer the second definition, "the state or quality of being productive", because we should be thinking about the productivity of the team. We should be thinking about how this outcome is to the end customer. We shouldn't be thinking about "is that particular developer 100 percent utilized?"
[00:02:38] We should be thinking about, as a team, as an organization, are we producing value? And that's normally into the hands of the customer. So you have to work back from that. If we're not producing value to the customer, we may be busy. We may have a developer working 100 percent. But are we actually producing anything valuable? And as such, are we producing anything that we consider productive value?
[00:03:10] There's any number of sources for poor productivity. And I've talked about technical debt before as a way of trying to summarize some of it.
[00:03:19] So technical debt is an analogy based on financial debt. We may choose to take a loan out to achieve a certain task and acknowledge that we're going to be paying that debt over the longer term in terms of interest payments. So in terms of technically, we may choose to cut technical corners, we may choose not to implement the correct level of testing. We may make short cuts in terms of how we develop the code and we may choose to do that on purpose. But we have to do that, accepting that what we might be doing is actually affecting our longer term productivity if we are incurring technical debt, that is a fairly safe bet that our productivity, our productivity will be affected because we're paying an additional tax on top of any work that we're trying to do.
[00:04:12] Another source of poor productivity is interruptions and distractions. I've talked to before about software development being a lot about problem solving. A software developer needs to have their head in the right place to think about what it is they're doing. Thinking about how best they can achieve the outcomes they're being asked to achieve. They need to be able to think about the problem if they're constantly being distracted or being interrupted. Then that's a very difficult thing to do, think about when you've tried to solve a problem. Sometimes you just need to be able to get away, get your head down and step away from distraction. And that's the same with developers and developers doing this day in, day out.
[00:04:56] One of the biggest distractions we can find are meetings.
[00:05:00] I'm not going to say meetings are a bad thing, because I think meetings can be a useful exercise, but more often than not, we invite software developers to a meeting as a means of mass distribution or maybe even a status update where it could be achieved in a better way.
[00:05:17] If we're calling short regular meetings throughout the day, this might seem beneficial to the team, but it is breaking the developers concentration. Breaking their ability to think about the problem they're working on. Is breaking their flow in terms of trying to be productive.
[00:05:35] And we have to think seriously at any time where we are asking a software developer or anyone else that is a knowledge worker to attend a meeting; Is the potential value of that meeting greater then the impact we're causing to the individual. And thus the team and thus the organization and thus the end customer in terms of the work they're trying to produce.
[00:06:01] Sometimes it can be as simple as trying to organize meetings at specific times when everybody knows they can plan their work around it.
[00:06:09] I'll come back to meetings probably in a future episode, because it is a very key interruption when it comes to productivity and getting the best from our software development.
[00:06:20] While there's obviously many, many possible causes for poor productivity, don't forget morale. Morale, especially in this time of Covid-19 morale, can really affect an individual. They can be unsure of where the future is. They can be unsure of the health of the family, the friends. It really can have a really key impact on productivity because, again, it's a distraction. It's keeping them away from thinking about the things they need to do.
[00:06:48] We should also be trying to be realistic about productivity. I've met many business owners who think that they should be getting a full eight hours of productivity out of an individual. They turn up at nine o'clock. They should be working through to six o'clock and every single hour should be productive (except maybe the lunch break). But that isn't true. It's very, very difficult for a human to be productive for that length of time.
[00:07:16] What you'll find is you have core productive hours and this can depend on individual, but normally it's somewhere between two to four hours where we are at our most productive during any working day.
[00:07:27] Now, per individual, that might be different. Some people are better in the morning. Some people are better in the afternoon. Some people have short spurts where they can be productive for 15, 20 minutes and then need to step away. Others that get their head down and suddenly can do four hours work; and they themselves don't realize what they've been doing for four hours because they've been that lost in the work. So it is different per individual.
[00:07:50] But coming back to that key important aspect; you have to think about the hours in terms of you cannot expect someone to be productive for a full eight hour day.
[00:08:04] If nothing else, we need to think about all the other activities that go around being productive.
[00:08:10] We have to do certain things to help us to be productive. We need to talk to people. We need to understand what work we need to do. We need to share ideas. We need to, to an extent, plan our day, plan the work that we are working on. We need to think about and integrate with the team and make sure that we are all effectively working from the same hymn sheet. We should be singing the same song.
[00:08:34] Now, that might seem that that's counterproductive to be to being productive. That you're actually taking time away from what you may consider to be productive work, to have these checkpoints, to have these conversations?
[00:08:47] Well, what we're talking about is making sure that everything is in a good position so that when the developer sits down to be productive, they have everything they need. They understand the context. They understand how other members of the team will be working with them to accomplish the goals. They understand what the goal is. That's where the investment should be.
[00:09:09] Now, this is sometimes why I will come back to meetings being in a good thing, because those meetings can help us achieve that, but we have to be conscious that the meeting has to be helping us to achieve productivity.
[00:09:21] And that needs to be evolved.
[00:09:23] The team needs to learn how best to work with each other in terms of what they need to do to be the most productive. Are they best having a meeting first thing in the morning to catch up with each other, understand where they are, or are they better off actually being heads down first thing in the morning when they may feel more creative?
[00:09:43] A team will work through that and learn as they go, but you need to allow them the space to think about and experiment and work out what that is. And I've talked about this in terms of the agile retrospective in Episode 45, a meeting where the team come together and sit and discuss what's worked well for them, what hasn't worked well.
[00:10:04] It isn't a status meeting. It isn't a meeting to say this is where we are on Project X, this is where we are in Project Y, it's what helps the team to work better. How do they get better? What's working well for the productivity? Maybe it's as simple as they feel they need a whiteboard. Maybe they feel that they need a meeting table. Maybe they feel that the way they're testing is nonproductive, maybe they feel they're doing things that should or shouldn't be done. But the whole point is that the team have an ability to have that regular catch up and evolve that as a team.
[00:10:42] And again, that comes back to learning and an organization of learning, which I talked about for episodes 44 to 47.
[00:10:53] So why doesn't that happen? I think a lot of it comes down to that misunderstanding of productivity. I think so many people look at productivity as being a "we're putting eight hours of this developer in, we should be getting X output out".
[00:11:11] And I come back to it's not about utilization.
[00:11:14] And that's probably one of the key problems we find so much in software development that the belief is we should be trying to sweat the asset. We should be thinking of them as being someone on a production line. We should be thinking about almost in a Taylorism type management style where we can expect them to follow a set procedure and to get the most out of their time that we're paying them for.
[00:11:39] That isn't how it works. It's very much about giving them time to think and understand what they need to do. It is knowledge work. You cannot manage them in the same way as a production line. It is entirely the wrong way to manage people.
[00:11:53] We can't be looking at just individual focus.
[00:11:57] We must be looking at the team and the organization as a whole as to what value we want to get from it, and that value will ultimately be down to what the end customer is paying us for. So we need to be thinking about how do we get to the point where the customer is happy to pass over whatever it is we consider of value, whether that's money or something else.
[00:12:22] So we need to be thinking about how do we make sure that the organization and then the team are producing value and being productive, much more so than just an individual.
[00:12:32] Individual productivity does not necessarily equate to a team or organization doing well or producing value. It's easy to understand an individual being very productive, but that work never going anywhere because the team or the organization never use it. They the individual might have been very productive, but it's wasteful productivity.
[00:12:53] If there's no value coming out of it from the customer, then it's meaningless.
[00:13:00] In the next 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:13:15] Thank you for listening. And I look forward to speaking to you again next week.