Karl Wiegers, Principal Consultant with Process Impact and author of 13 books, discusses specific practices based on his 50 years’ experience in the software industry that can help and affect many software projects. Host Gavin Henry spoke with Wiegers about common problems in software development, including technical debt; staff scaling; iron triangles; changes over the past 50 years (or rather, what hasn’t changed); how to approach requirements gathering with use cases; design iteration and abstraction; prototyping; modeling; project management; negotiating around constraints; product scopes; schedules, budgets, and staffing; product quality; teamwork and culture; defining quality; process improvement; and self-learning. In short, the goal of the episode is to help ensure that you don’t repeat the things he sees time and time again with nearly every customer and organization he works with.
Show Notes
Related Links
- LinkedIn Profile
- Personal home page – https://www.karlwiegers.com/
- Business home page – Process Impact — Software Process Improvement Consulting and Education
- Books by Karl Wiegers
- Software Development Pearls
- Wikipedia – Karl Wiegers
Computer Society Digital Library
- Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort
- Choice of Software Development Methodologies: Do Organizational, Project, and Team Characteristics Matter?
- Integrating Technical Debt Management and Software Quality Management Processes: A Framework and Field Tests
Related Episodes
- Episode 481: Ipek Ozkaya on Managing Technical Debt
- Episode 355: Randy Shoup on Scaling Technology and Organization
- Episode 352: Johnathan Nightingale on Scaling Engineering Management
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Gavin Henry 00:00:16 Welcome to Software Engineering Radio. I’m your host, Gavin Henry, and today my guest is Karl Wiegers. Karl Wiegers is Principle Consultant with Process Impact, a Software Development Consulting and Training company in Portland, Oregon. He has a PhD in Organic Chemistry, which we’ll touch upon later. Karl is the author of 13 books, including Software Development Pearls, which we’re going to talk about today. The Thoughtless Design of Everyday Things, Software Requirements, Successful Business Analysis Consulting, and a forensic mystery novel titled The Reconstruction. He has delivered hundreds of training courses, webinars, and conference presentations, worldwide. Karl, welcome to Software Engineering Radio.
Karl Wiegers 00:00:59 Well, hi, Gavin. Thanks very much for having me. I’m happy to be with you today.
Gavin Henry 00:01:40 I’d like to start with a brief history of your background in software, and then I’ve broken the show up into hopefully six blocks of around 10 minutes each, so we can dig into various sections I found good in your book. So, we’ll see how we get on; we’ll do our best. So, first of all, I’d like to address the fact that your book says 50 years of experience. Has that been a volatile 50 years of change, or was there more or less change during certain periods? What stands out for you during those 50 amazing years of career?
Karl Wiegers 00:02:17 Yeah, it’s hard for me to believe it’s been that long. In fact, it was 50 years when I started writing Software Development Pearls. I first learned to program in college in 1970, which is almost 52 years ago in September. And I did a lot of programming in different situations there and also in graduate school, in Chemistry at the University of Illinois. I did a lot of software development for various reasons and started out my career at Kodak in Rochester, New York, as a research scientist. And then after a few years, I moved into full-time software development. And what was interesting is I also became an Atari hobbyist — remember Atari computers? Maybe you’re too young for that, but I was an Atari hobbyist, and I did a huge of programming at home and even wrote the assembly language tutorial column for a hobby magazine for two years and even programmed some commercial educational games.
Karl Wiegers 00:03:09 So, I did a lot of different kinds of things in software. I moved from software development into software management and then into a more of a quality engineering and process improvement kind of role and started my company Process Impact in 1997. Plus of course, like all of us, I’ve got a lot of experience as a user and, you know, a lot has changed in the last 50 years about software and software engineering. But one thing I think that’s interesting Gavin is that some things really haven’t changed as much as you might think. For example, requirements development. That’s an area I’ve done quite a bit of work in. That’s not really a technical problem. That’s a communication problem or a thinking and business kind of problem primarily. So, a lot of the challenges that people faced with the requirements long ago, or still valid.
Gavin Henry 00:03:56 That leads us nicely onto the first section of the show. So you mentioned requirements. This is spot on for where I’m going with the show. So, in lesson four of your book, you say a user-centric approach to requirements will meet customer needs better than a feature-centric approach. So I think that is understanding or trying to understand what they want from something rather than the features. Could you explain that better than me and take us through that?
Karl Wiegers 00:05:15 Yeah, there’s two separate but related concepts here. You know, the first is user engagement, and I think we all talk about users, but sometimes I don’t think we do a good enough job of understanding who our users really are. So, I think it’s important to do some stakeholder analysis and then identify your user classes — user classes being distinct groups of users who have largely different, maybe not completely orthogonal, but largely different needs and tasks they need to perform with the system. So, we did that for an information system project I worked on at Kodak called the chemical tracking system where I was the lead BA for the third attempt to get this project done (the first two had failed for some reason). And we identified four distinct user communities with largely different needs. So that’s a good start, but then you have to say, all right, so who do I talk to?
Karl Wiegers 00:06:07 Who do I get requirements from that I can trust? And so in other words, who’s going to be the literal voice of the customer for each of these groups? So when I was at Kodak, we started this idea clear back in 1985 of having “product champions” was the term that we used for having key representatives for these user groups. And those were the people that the business analysts would work to try to understand their requirements. And then we get to the second part of that question about usage-centric versus feature-centric, which is to focus on understanding what users need to do with the system, not just the features they want to have built into the system. And this was a really profound moment. You asked earlier Gavin about times of change in the last 50 years. And one of the really profound changes in my thinking about software engineering was when I realized, first of all, that there are different kinds of requirements, which I classify very broadly: there’s business requirements, user requirements, and functional or solution requirements.
Karl Wiegers 00:07:12 But then the real insight I had was when I learned about use cases. And I realized that if we talk about what people need to do with the system, we learn a lot more than if we just ask people, well, what do you want? And the first time I applied the use case technique was on that chemical tracking system, which the previous business analysts had not managed to get anywhere with. And it worked remarkably well. All of the user representatives we worked with really found that approach comfortable and satisfactory and natural when we’re talking about, “well, what are the things you need to do with the system?” rather than what the system should do, itself. So I really got sold on use cases and this usage-centric thinking.
Gavin Henry 00:07:54 And does that fall under any type of model that’s given a name today, a type of practice or something, or is it encapsulated in requirements?
Karl Wiegers 00:08:05 Well, that’s a good question. I think the use case rubric overall, I think, is kind of the overarching theme there. And you do hear people about use cases actually in daily life sometimes now, even though I’m not sure they’re using the term exactly as we do in software, but it’s the same idea. And the reason I think this is so important — so, I’m not sure there’s a general methodology, but if we focus on that idea of usage-centric requirements exploration and usage-centric design that solves a lot of problems. If you ask the traditional question during requirements discussions, “what do you want?” or “what are your requirements?” — those are terrible questions. What they do is they open the door, and then maybe you’ve had this experience: You just start getting this random pile of information that’s really hard to turn into a set of useful requirements that leads to a decent solution. And also another thing that happens, you can focus on features, so you implement functionality that doesn’t actually let users do their job. Or you can implement functionality that no one’s ever going to use, but you work pretty hard on building that even if they don’t use it. So that’s pretty discouraging too.
Gavin Henry 00:09:16 And why do you think this normally goes wrong even today?
Karl Wiegers 00:09:20 Well, I think it goes wrong if people aren’t talking to the right representatives who can really represent the needs of a community of users, like a particular user class. It goes wrong if we leave it so open-ended and just ask people what they want and they free associate and they think, “well, it should let me sort this list this way.” And then you miss the gist of, well, what is the task you’re trying to accomplish? And one way that I try to phrase that question is, think in terms of, okay, so here’s an app; you’re going to launch the app. What are you trying to accomplish when you launch a session with the app? You’re not launching it to use some feature; you’re launching it to get something done. Even if it’s a game, you’re trying to get something done, or if it’s a device, or it’s a software application, you launch it for a reason.
Karl Wiegers 00:10:10 So, by trying to understand the reasons people are using it and what they’re trying to accomplish, then we go a lot more to the right side of understanding. All right, well, what functionality do we have to build to let you do that? And are we sure that that all aligns with our business objectives? So it goes wrong if you don’t take that kind of approach, and I can give you a great example. So, I’ve been a consultant for about 25 years. One of my consulting clients once held a big one-day offsite workshop. They had about 60 participants, and they called this a requirements workshop. Broke them into six subgroups to collect what they considered to be requirements for a big product this company was working on — this was a commercial product. So, took all the output from those six subgroups and basically stapled it together, literally and verbatim.
Karl Wiegers 00:10:59 And said, well here’s our requirement specification. But it wasn’t. That’s what I call a pile. There were a lot of useful and important pieces of information in there, but it wasn’t structured or organized in any useful way. Everything was stirred together. There was a lot of extraneous information and ideas and thoughts, just all, all thrown in. So, just asking people to brainstorm what they wanted didn’t produce any actionable requirements knowledge, although there was probably a pony buried in there somewhere, but that form of having the conversation didn’t lend itself to getting the information you need to say okay, what is it we need to build?
Gavin Henry 00:11:36 If they did take that big pile of stapled information and then came back with something weeks or months later, that’s your traditional waterfall with no requirements engagement at all, isn’t it?
Karl Wiegers 00:11:47 Yeah. And it’s even worse because you started with a really bad bucket of water to dump over the waterfall at the outset. So, I think what we really want to try to do, besides having the ongoing customer engagement rather than just trying to do it once at the beginning — we all know that doesn’t work well; I think ongoing touchpoints throughout the project is really important — but by asking the right kinds of questions and then taking the information and organizing it and structuring it in a way. And I find use cases work very well for that because my brain is kind of top-down, and I think it’s better to start with some broad strokes or some higher abstraction thinking like, well, what are the tasks we’re trying to accomplish? And then elaborate the details over time at the right time as opposed to collecting this huge pile of information and then trying to organize it and sort it out and say, well, what do I do with this?
Karl Wiegers 00:12:44 In fact, I’ve got a great example of how I’ve seen that happen. So I’ve taught more than 200 courses on requirements to audiences of all kinds. And one of the things I do in those courses is I have the students participate in a practice requirements-elicitation session after I’ve described the use case approach. I break the group into four small teams, and I’ve seen the same pattern over and over hundreds of times. Now, one of those four teams always seems to grasp the idea of use cases, maybe because someone’s worked with them before, and they make great progress in that one-hour practice elicitation session. Two of the other groups need a little coaching on how to get going with use cases, and then they do fine. But the fourth group almost invariably struggles because they don’t try what I’m trying to get them to do, which is talk about use cases.
Karl Wiegers 00:13:33 They start in the traditional way of asking the people who are role playing the users, “Well, what do you want?” And as a result, just like I did with that consulting client, the facilitator ends up with this list of random bits of information that are potentially useful, but there’s no structure, no focus, no relationship to what the users are going to do with the system. And I’ve seen this over and over. Then the team just sorts of sort of stares at the flip chart that’s got these post-it notes all over it with these thoughts and feature ideas, and they what to do next. So after seeing that over and over, I think that pretty well sells me on the usage-centric thinking.
Gavin Henry 00:14:15 Is this something that you just do once at the start, or are you constantly revisiting and revalidating?
Karl Wiegers 00:14:22 Well, you mean on a real project? Well, the term that I use that I think is applicable is “progressive refinement of detail.” And so, I think of maybe doing a first cut to say let’s identify these use cases; let’s take a user group and let’s talk about what are the things, the major things, you’d need to do with the system. And that’s what we did on the chemical tracking system project. And then we can do a first cut prioritization and say, well, which of those are going to be more common or heavily used by lots of people, and which ones are going to be more once in a while or only certain users? And that helps you start thinking very early about prioritizing your development approach, whether you’re doing it one time through the project or you’re doing it in small increments. And then you can take each of those based on their priority and start refining them into further amounts of detail to get a richer understanding. And yes, you do have to revisit that as we go along, because people will think of new things. People will realize that maybe something someone suggested is now obsolete in our business or whatever. So, I think it has to be a dynamic ongoing thing, but that’s why I use the term progressive refinement of detail rather than trying to get that all right away.
Gavin Henry 00:15:34 Thank you. I’d like to discuss now what you call design. In lesson 18, you state it’s cheaper to iterate at higher levels of abstraction. Can you take us through abstraction, prototyping, modeling, designs, things like that?
Karl Wiegers 00:15:51 Sure. So, when I’m thinking about higher levels of abstraction, you can imagine a scale where at the highest level of abstraction, you’ve got a concept for a project or a product, let’s say. And then as you move down this abstraction scale a little bit, you start talking about requirements, and maybe you start doing some prototyping or modeling. So, we start progressively moving from concept to something that’s more tangible. And at the lowest level of abstraction when you’re building a piece of software, you have code. That’s the ultimate reality, of course, but all those things expand as you’re going down that abstraction scale. So, the idea behind that lesson, that it’s cheaper to iterate at higher levels of abstraction is that, first of all, it’s nearly I to get a design right — that is, an optimized solution — on your first try. At least, I can’t do it. It usually takes multiple attempts, kind of refining my understanding of both the problem and potential solutions on each cycle.
Karl Wiegers 00:16:48 So we want to think of how can you iterate? One way is to write the code over and over trying to get the solution right. And that’s iteration at a low level of abstraction. Or you can try to iterate at higher levels — like concepts, the requirements, models, prototypes — and it takes less work to create each of those kinds of artifacts on each iterative pass than it does doing code. So you can iterate more quickly and more times. And I think that gives you more chances of getting it right. Has that been your experience that it takes more than one try to get kind of the solution that you feel best about?
Gavin Henry 00:17:24 Yeah, I think starting off with the design first and then moving into requirements in a project where you have the idea, but things appear as you move forward and then you have to tackle them. And I think that fits nicely with how you say your requirements constantly change as you think about and discuss parts of a project. Your example was the chemical software application. Is that an analysis, or what sort of application was it?
Karl Wiegers 00:17:51 It was a tracking system. So it was basically a database application where we could keep track of all the thousands and thousands of bottles of different chemicals, both in the stockroom inventories throughout this very large company and also in individual laboratories, so that we could just order new chemicals, maybe try to find a bottle that’s already around somewhere in the company so you don’t have to buy a new bottle from a vendor, maybe dispose safely of expired chemicals, and that sort thing. So it was a big inventory system, essentially, with a lot of tracking of individual containers. That’s what it was about.
Gavin Henry 00:18:25 So, in the two lessons that we just spoke about, would the design have come first or the use case of we want to manage and track?
Karl Wiegers 00:18:32 Absolutely the use cases. Absolutely start with the use cases because how do I know what to design until I know what functionality it has to provide? And how do I know what functionality it has to provide until I know what people are trying to accomplish with it?
Gavin Henry 00:18:46 But that’s tricky because the way you can phrase a sentence in English, you could say, I need to design a chemical-tracking application couldn’t you? Or you could say my requirements are a chemical-tracking application.
Karl Wiegers 00:18:59 Yeah. So that would be the super highest level of abstraction. Right? That’s a concept. But that doesn’t tell you anything about the solution; it tells you about your business objectives, maybe, you know? And I think you do really need to start with an understanding of the business objectives, which is, “why do we need to build a chemical-tracking system?”
Gavin Henry 00:19:15 Which comes back to the requirements, yeah.
Karl Wiegers 00:19:17 Right. So that’s that top level of requirements or our business objectives, which is really the motivation of why are we spending money and time on this instead of on something else? You know, what’s it going to do for us? What financial benefit or compliance benefit or whatever are we trying to accomplish with that? And that I think then helps to start identifying your stakeholders, start identifying these user classes. And then I find use cases are just an excellent way to have the conversation initially with those users to say, all right, if we need this system — and one of the big drivers for it was compliance, there were regulations that said, you guys have to report to the government, how you’re disposing of chemicals and storing them safely and all that. That was our major business driver.
Gavin Henry 00:20:00 So not just potential commercial wastage.
Karl Wiegers 00:20:03 No, that was kind of a nice side benefit. But the principal driver and the key customer was the guy who was responsible for managing reports to the government for health and safety purposes of how the chemicals were being acquired, stored, and disposed of in the Genesee River. I mean the cafeteria, you know, wherever they got rid of them.
Gavin Henry 00:20:22 So yeah, if you didn’t do the use cases correctly there, you might go down the feature-centric or the wrong approach where you think you’re trying to save money, or you’re trying to find something quickly, or find out when’s expired, but that’s not the top-level thing you’re trying to do.
Karl Wiegers 00:20:37 That was an important component of it, but it wasn’t the key driver. So that’s why I think you need this sort of stack of requirements. And that was a big eye opener for me is when I realized, ah, there are different kinds of things we call requirements. There are different kinds of things we call design. We need to put adjectives in front of them. And so, even having an understanding then of the major tasks people need to accomplish with this that will hopefully achieve our business objectives, you still need to design the software, the architecture, the detail design, the database design, the user experience design. And I found prototypes were a very good way to help with that iteration. It helps bring clarity to the problem, to the requirements, and to the possible solutions, because it’s so much easier for users to react to something that you put in front of them, instead of just relying on this abstraction of requirement statements or user stories.
Karl Wiegers 00:21:32 So I became a big fan of design modeling and analysis modeling as well. That was another real turning point in my career. You asked about the big changes and that was another big one. When I took a class on structured systems analysis and design and I realized, wow, before I sit down and just start writing code, I can learn a great deal and think a great deal and understand much better if I draw pictures to represent my proposed system or my problem at a higher level of abstraction than just writing code or writing text. I found that extremely powerful. So I’ve been a big fan of modeling for a time because it’s a lot easier to change models. It’s a lot easier to change prototypes than it is to change a system you think you’re done with.
Gavin Henry 00:22:20 So how do you constantly design something? Do you reach back to what you’ve just said there, prototyping and proving the idea?
Karl Wiegers 00:22:25 Well, I wouldn’t say you “constantly” design it, I would say you “repeatedly” design it. That is, you take multiple attempts to come up with a design that’s progressively better each time. And then you build from your best design. I’ll give you an example. I have a friend who’s a highly experienced designer, and he said, you haven’t done your design job if you haven’t thought of at least three solutions, discarded all of them because they weren’t good enough, and then combined the best parts of all of them into a superior fourth solution. So, what we don’t want to do, I think, is be designing continuously while you’re trying to build the application as well. And I think unfortunately that happens sometimes; people tend to not think of design as a discrete development stage or discrete thought process, and people who are building systems hastily in a rush to get them out — like, maybe on some agile projects — they might skimp on design. They build something, and it, it works. And we say, okay, but then they are having to constantly redesign what they’ve done, perhaps to extend it, to accommodate new functionality. And that’s where you have to do a lot of refactoring and that sort of thing, and architectural changes. And I don’t think we should use that kind of continuous design and redesign as a substitute for doing some careful thinking before you sit down to write a lot of code.
Gavin Henry 00:23:47 Yeah. There’s a lot you can do up front before your key fingers touch the keyboard.
Karl Wiegers 00:23:52 Right. And you’re always going to change because you’re going to learn new things, and businesses change, approaches and technologies change. So you have to be able to adapt to that. But I don’t think the idea of look well, we can build code really quickly, we can refactor it for the next iteration. I don’t think that should be a substitute for thinking.
Gavin Henry 00:24:10 And there must be a point where you get so far along that you can’t change the design. How do you manage that?
Karl Wiegers 00:24:17 Well, that becomes very expensive, right? And a good example of when that can happen is if people have not done a thoughtful job about exploring some nonfunctional requirements along with the functionality. And that’s one of the tricky things about requirements is that the part that people naturally think of when you’re discussing requirements is the functionality, the behaviors the system’s going to exhibit under certain conditions as you try to do things, but we also have all kinds of nonfunctional requirements, a lot of which are in the category of quality attributes, the so-called -ilities, right? usability, portability, maintainability. Some of these are internal to the system, more important to developers and maintainers. Some of them are external and more important to users, like security and availability. But if we don’t make that an important part of our requirements exploration, then we can have a problem just like you’re getting at, Gavin, because some of those have pretty profound implications for both functionality to be added and architectural issues.
Karl Wiegers 00:25:20 And if you don’t think about, for example, certain reliability things, well in some kind of products where reliability may be critical, you may end up building it and saying, oh, this, this does what we need, but it crashes too often. I can’t trust it to, you know, do those communications as we need to. And rearchitecting that can be pretty expensive, or sometimes maybe essentially impossible. That’s where you get into trouble. So I think the nonfunctional aspects of the system have to be explored carefully along with the functionality, because you don’t just write down, you know, the system’s availability requirements on a story card and then patch it in when you get around to it. That just doesn’t work.
Gavin Henry 00:26:00 Thank you. I’d like to move us on to project management. So, in our journey, we’ve got the chemical …
Karl Wiegers 00:26:07 Tracking system.
Gavin Henry 00:26:08 Tracking system. Yeah, sorry. We’ve done enough user requirements, use cases, up front to get going. We’re potentially starting a prototype and some design models that we’ve maybe done three of and chucked them out and started again. But we’re on our way. So we obviously need to manage the project now. So, lesson 31 in your book talks about the project team needs flexibility around at least one of the five dimensions of scope, schedule, budget, staff, and quality. So, I guess that’s the five things: scope, schedule, budget, staff, quality. Can you take us through that?
Karl Wiegers 00:26:44 Yeah. This is kind of getting back to an extension of an idea that most project managers are familiar with. They’ve heard of the classic “iron triangle” sometimes called the “triple constraint” of project management. And the colloquial statement of that is, you know, a sign you might see at a gas station when you take your car in, what do you want? Good, fast, or cheap: pick two. You know, the idea that you can’t have everything that you want necessarily; there’s some competition, some trade-offs. And the problem I had with that classic iron triangle is that, first, I’ve seen it drawn in multiple ways with different labels on the vertices. The most common ones are time, cost, and scope on three vertices of the triangle. And we’re all familiar with those trade-offs. Sometimes quality shows up in the triangle, but sometimes it doesn’t; sometimes it’s sort of in the middle, but I don’t know what that means.
Karl Wiegers 00:27:38 Does that mean quality is a given, so that all the other parameters have to be adjusted to get high quality, maybe? Or does it mean, well you get whatever quality you get within the constraints that these other parameters impose? That’s not clear. So, I was never comfortable with that representation. And so, I came up with this idea of these five dimensions that you mentioned — scope, schedule, budget, staff, and quality. Sometimes people put in risk, but risk really isn’t adjustable in the same way that these others are. And the fact is people do make trade-offs with these against each other, including quality, all the time. People might decide to ship a product that they know is defective. In some ways, with the idea rightly or wrongly that, from a business point of view, it’s better to get the product out there fast than it is to make sure that everything works right.
Karl Wiegers 00:28:29 Although I don’t think customers always agree with that attitude. So I try to also split resources that you see sometimes in that iron triangle into budget and staff, two different aspects of resources. I’ve known of teams that had funding, but they had a headcount limitation. They couldn’t hire new people, but they could use that money in other ways, maybe outsourcing or buying a package solution or something. So the idea behind this lesson is that there are these trade-offs people have to make, and constraints they have to work within if they want to be successful.
Gavin Henry 00:29:03 And would you say that those five things are applicable whether it’s a business application, hobbyist application, or… you know, because obviously if it’s a hobby one, you might not want to spend any money, but the staff level is just you, the quality is as good as you want to make it, and the schedule is as quick as you want to do it.
Karl Wiegers 00:29:23 But right. So that’s a little different situation for most commercial or business situations,
Gavin Henry 00:29:28 But it still sounds like it’s applicable though.
Karl Wiegers 00:29:31 I think it is. I can tell you kind of how this works why we need to do this analysis of those different dimensions. So I was teaching a class on project management once at a, a state government agency and a woman in the class after I talked about this, raised her hand and she said, all right, so here’s our situation. We’ve got a fixed feature set that all has to be delivered. There can’t be any defects we’ve got to schedule and has to be done on time. I can’t get more money. The budget’s fixed and I can’t get more people, more staff if I need them. So what do I do?
Gavin Henry 00:30:03 That means none of the five are negotiable. That
Karl Wiegers 00:30:06 Exactly right. Gavin, that’s exactly the point. And my point was is you will fail because if you don’t have everything perfect then you’re going to have some, , limitations here. The first estimate that turns out to be low. Someone who decides to leave the company unexpectedly the first time someone comes along and says, Hey, could you add this? Any of those kinds of changes, you don’t have any way to respond to them. You need some flexibility around certain of those dimensions. And as you were alluding to a few minutes ago, depending on the nature of your project, certain of those dimensions may not be flexible. You know, they may be constraints, Y2K projects were time constrained, right. That had to be done on a certain date. And that’s true of things like, okay, the Euro conversion Brexit, all of those things had time constraints.
Karl Wiegers 00:30:56 So schedule was a constraint. You didn’t have any choice. So that means something else has to be flexible. So I think of a constraint as being a dimension about which you have no flexibility. The project managers just has to deal with that reality. The second category a dimension could fall into is what I call a, a driver and a driver is one of the major kind of success objectives for the project, which they have a little bit of flexibility, but it’s important to try to achieve that. And any dimension, that’s not a constraint or not a driver is a degree of freedom, which has a certain amount of adjustability to it. And the project manager needs to know how much adjustability. So the trick, and this is the balancing point for any kind of project is to do some analysis. You understand what’s critical, what’s constrained. Is it schedule, is it quality? You know, for a, a life critical system? You know, we’d probably rather ship it a month late. If you have to, to make sure you don’t kill somebody with it. So the project manager has to try to achieve the success drivers by adjusting the degrees of freedom within the limits, imposed by the constraints.
Gavin Henry 00:32:06 So success could be, we have to get it delivered by, you know, the 1st of July. And then you’ve got, you can negotiate around the other four, or you might say, we can’t hire any more staff, but we’re flexible on how much it costs or, you know, those types of things,
Karl Wiegers 00:32:22 Right. Or you’ve got to prioritize feature sets so that you can say, well, we we’ve got to have these basic features, but beyond that, there’s some flexibility and you know, how many more we can include with our fixed team size and our fixed schedule constraint. So you have to know which ones of those are adjustable for and a good way to have that conversation is suppose you’re talking to a manager, customer project sponsor, and they say, okay, this has to be delivered by July 1st. Well, ask the question. What happens if it’s not delivered by July 1st?
Gavin Henry 00:32:51 Yeah, I was going to ask them, who’s dictating that the, the customer, the internal staff, the
Karl Wiegers 00:32:56 Right, so challenge that you know, or at least inquire about it to understand. I mean, you’re not saying no you’re saying help me understand what happens if we’re not done by then. And maybe the answer is, well, we’re going to get a fine of 20,000 Euro a day because we’re not in compliance with some important regulation. Well, that’s a pretty serious consequence. That sounds like a constraint to me. So July 1st it is. But what if the answer is well, we’d like it by July 1st, you know, to go along with our other product launches, but you know, if we didn’t make it out till the third week of July, we can live with that. Okay. It’s a success driver, but it’s not a constraint. So you need to know which ones are adjustable and how much adjustment there is in there, how much flexibility so you can adapt to changing realities
Gavin Henry 00:33:40 And hopefully some of this has been caught in the requirements stage.
Karl Wiegers 00:33:43 Well, I think it’s really part of the project planning stage. And you could understand, I think that from more from a business point of view than from a specific software or solution requirements of view from a business perspective, you’ll know what’s constrained. If you’re working in a company you’re that limits the I that’s business or requirements perspective.
Gavin Henry 00:34:11 Is there a common theme you’ve seen in your commercial training and consultancy?
Karl Wiegers 00:34:15 Well, it varies a lot. I mean, what everybody really wants, I think is they would like an application that has all the functionality anybody would ever want with zero defects, instantaneous response time delivered tomorrow for free. I don’t know how to do that. and so obviously we compromise in some of those areas, right. And it’s going to vary from situation to situation. But one of the common patterns that I think is one to watch out for is treating quality as a default adjustable parameter. In other words, well, yeah, it’s got some bugs in it, but it’s Thursday. And we, we said we were going to ship it on Thursday, so we got to ship it. Cause we’re done now it’s Thursday. And that I think is shortsighted, partly because, you know, customers don’t like bugs. I remember reading a, an interview with bill gates many years ago when he was at Microsoft and the interviewer asked, well, how do you respond to the complaint from users that Microsoft software has a lot of bugs?
Karl Wiegers 00:35:12 And the answer was, and I believe this is a verbatim quote. Our users don’t care about bugs. They care about features. I’ve never spoken to anyone who agrees with that. So I think too often the default is, well, the quality is whatever it is and will answer the phone if it rings. And I don’t really agree with that in every case, but there may be certain cases, like if you’re trying to be first to market with a highly innovative project and your target market is early adopter innovator people, maybe that’s okay. So it’s a business decision.
Gavin Henry 00:35:39 Yeah. I’m going to move us on to the next session just so I can keep us on track with time. Cause I want to get a lot covered with you, but just to close off that section in the network engineering world that I triangle, which is the first time I’ve heard of it, but we call it, you make a choice between fast, cheap, and reliable. So if you’re going to buy a router or a router, if you want it fast and reliable, it’s not going to be cheap. So I just thought Chuck that in there, if we move on to culture and teamwork, so knowledge is not zero sum. This is less than 35 in your book. And what ways can culture and teamwork positively and negatively impact a software project? For example, the one we’re talking about chemical,
Karl Wiegers 00:36:20 Well, this lesson gets to one of those aspects of how culture and teamwork can affect the project. And let me tell you what I mean when I talk about culture, I think a healthy software engineering culture is characterized by a set of shared values and technical practices that lead to constructive and congruent. That’s important behaviors on the team. And I talk about this in my very first book, which was published back in 1996 and called creating a software engineering culture and the willingness to freely share knowledge among team members and to comfortably seek knowledge from your colleagues. That’s one of those constructive behaviors. I had a great counter example of that that helped bring used to work with guy Ron older. He’d around a little longer at Kodak would ask a and almost go ask on a question and I could almost see the wheels in his brain working.
Karl Wiegers 00:37:13 He’d be thinking well, if I give Karl the whole answer to his question, he’ll be as smart as me about that. I don’t want that. So I’m going to give him half the answer and see if he goes away. So then you come back for another ha half of the answer and, and that’s all you get. You want the rest of the answer, you just get another half. So you ask himally approach, getting an answer. And I just didn’t appreciate that. I think when we’re working together, we should be willing to share what we know with other people. And that positively affects a team because we all do better when we all know more and we all are willing to ask for help or get somebody to look over our shoulder at something. So I, I think that that’s a real important way to improve the culture.
Karl Wiegers 00:37:53 As another example, in that creating a software engineering culture book I described 14 principles that our small software team in the Kodak research labs had adopted a shared values. And one of them was that we would rather have a coworker find a defect instead of having a customer find a defect. And as a result, we routinely practiced technical peer reviews of each other’s work. It was just ingrained in our culture. We rewarded people who participated in the reviews and who submitted their work to review by their colleagues, but we didn’t punish people based on how many defects we found that would be a real culture killer. Now, if someone joined our group who didn’t want to participate in reviews, for whatever reason, there’s going to be a culture clash and that just wouldn’t be the right place for them to work. So I think having those kinds of factors to steer a culture in a collaborative, effective direction is really critical. And managers play a big role in shaping that culture by helping to establish those principles and values and by exhibiting behaviors that are consistent with those. Have you ever seen a case where management said they valued one thing like quality, but then they rewarded different behaviors like people who delivered on time without necessarily delivering quality and then people had to fix it. You ever seen that kind of incongruence?
Gavin Henry 00:39:07 Yeah. It depends two immediate questions that spring to mind when you talk about giving a colleague this full answer and also peer review obviously has to be encouraged and that time needs to be there by the management to allow you to do that. But how do you figure out whether they’ve put enough effort in for you to justify giving them a full answer rather than just trying to get the answer out of
Karl Wiegers 00:39:29 You? Exactly. No, that’s a good question. And I think you do have to kind of judge, are you trying to get me to do your thinking for you or are you just relying on my experience in this particular area so that I can give you an answer faster than, than you might have dug it up on your own and probably a better answer based on my experience rather than just whatever you found online. And I think that’s a situational judgment, I think in a software team or any team, really, we all know who the top performers are. We all know who’s coasting or struggling, or maybe just trying to get other people to do their work for them. I don’t think that’s a secret. And if I was working in a team and the same person kept coming to me with what seemed like relatively straightforward questions, things they should already know the answers to things. They should have been able to look into themselves. That’s a problem. But if I’m on the other hand, people come to me because I have certain expertise that they don’t have. And I can impart that thereby giving them some of that expertise on their own, which they now own forever. We all win. So it is a tradeoff decision. But I think in each case you just have to kind of assess the situation and see which of those scenarios we’re talking about.
Gavin Henry 00:40:40 Yeah. You could always ask what have you tried? And then also judge, well, if I spend a bit more time with you right now, hopefully that’ll self-power you to do it yourself next time,
Karl Wiegers 00:40:50 Right? You’re just kind of giving them a start and point and maybe help is simply pointing them towards resources and say, look, here’s a book I found really helpful. Or here’s a couple of articles. I I’ll answer your question. Why don’t check those out. There’s something you don’t understand. So I think we can handle that in an equitable way without, you know, just ending up doing everybody else’s work cause you happen to know stuff.
Gavin Henry 00:41:11 And you mentioned peer review and preferring your colleagues to find issues or bugs. Is that something that, you know, you mentioned management, do they need to buy into that? How do you do that? If totally. If one of your constraints and the five constraints of scope, schedule, budget, staff and quality is schedule, you know, where do you find that time to keep the quality up?
Karl Wiegers 00:41:32 Ah, you’re raising a very, very interesting and important point here, Gavin. Okay. So let’s say our constraint is schedule. And what you’re saying is, dude, we’ve got a certain amount of time. We got to get a certain amount of work in, and you’re saying if I, maybe you’re thinking as well, if I’m on that team and if I spend two hours reviewing this person’s code or requirements or whatever, then that’s two hours. I’m not spending on my own project to get my work done. So I’m behind schedule. And the fact is that well, conducted reviews almost always pay off more than they cost. That is the time you spend collectively on a review, finds enough defects early enough that you can fix them quickly and cheaply rather than having them get into the final product and have the customer call you later so that you come out ahead by doing that.
Karl Wiegers 00:42:22 Now, if reviews are not effective in terms of actually finding problems or in that rare case where you don’t have any problems to be found, then that payoff doesn’t come through. But my experience has been, there’s almost always a high return on investment from people once they get into an effective review culture. So that’s one way to think about it. It’s not just what I pay today. It’s what do I reap downstream by avoided rework because of what I pay today. And the second way to think about it is that whenever you’re asked to do something different or extra your immediate reactions to think, well, what’s in it for me, but the right way to think about it is what’s in it for us. And when you start thinking that way you become more willing, I think, to participate in shared quality activities.
Gavin Henry 00:43:08 And you could also be using that two-hour peer review and you’re staring at a bug that you’re already working on, you know, or you recognize something that you are doing. So you’re actually working on what you’re supposed to be working on, but helping someone else at the same time.
Karl Wiegers 00:43:21 Yeah. I’ve learned something from every review I’ve participated in. And I don’t know about you, but I’ve had the experience where I’m staring at that bug and I just can’t see it. And I ask somebody, Hey Jim, can you come take a look at this for me? I just can’t see this. And Jim, over your you’re explaining to him one of two things, either you figure it out while you’re explaining it, Jim says, I think maybe this comma is in the wrong place. Oh, that’s it just didn’t see it. Have you had those kind of experiences?
Gavin Henry 00:43:48 Yeah. Sometimes you think what’s in front of you and it’s not actually there, you you’ve switched that part, your brain off to say, right. I know what’s in that part of the, the project or the code,
Karl Wiegers 00:43:59 Right. You just need a little help from your friends sometimes. And that’s I
Gavin Henry 00:44:02 Think you’ve done a show
Karl Wiegers 00:44:02 Idea,
Gavin Henry 00:44:03 The rubber ducky technique and other things like that. Cool. Right. We’ve touched on the next action, which is perfect, which is called quality. So which tied us back into the peer review bit that we’ve just had a little chat about. So less than 45 in your book state, when it comes to software quality, you can pay now or pay more later, is this really true? And how do you define quality?
Karl Wiegers 00:44:28 Well, I think not only is there a lot of data published to support that argument, that it costs you more to fix problems later than earlier, but it just seems logical. I mean, the later in the development process or let alone after it’s in production, that you find a problem, the harder it is to debug it, to diagnose the failure and find the underlying fault. Also the later you find the problem, the more components you might have to modify to correct it, you know, requirements, designs, code, tests, and so on, and you can get this big ripple effect. If you have this cascading series of changes required, maybe even in multiple connected components or systems. So it stands to reason that if you could find, say a requirement or design error before you’ve completed implementation, based on that piece of knowledge, it’s going to cost less to deal with it. So we want to try to find defects as close as possible to the point in time at which they were injected into the development process. And I think that’s true regardless of the development life cycle or methodology that you’re following is always going to cost more to fix it later than earlier. It’s hard for me to imagine how that could not be true.
Gavin Henry 00:45:33 We need to define quality so we can test it and prove that we’ve got quality. And that ties us back to the use cases, the requirements, how do we make sure that our use cases of high quality so we can potentially write our test to prove that quality, maybe it’s best explained with an example that you’ve come across?
Karl Wiegers 00:45:53 Well, the whole definition of quality is kind of a funny concept. And when I was writing this book, I looked up some definitions of software or more generally product quality. And I found a lot of different definitions. They all had merit, but none of them were perfect for comprehensive. So I decided I, wasn’t going to try to presume to solve that problem and come up with a perfect definition of software quality. But I learned two things from that one quality has multiple aspects. You don’t just have a, you know, 10-word definition of quality that fits everything. Second quality situational. So I guess we could probably all agree that in the context of developed software quality describes how well the product does, whatever it’s supposed to do. And so instead of trying to find the perfect definition, I think it’s important for each team to what quality mean to its customers.
Karl Wiegers 00:46:45 How we, that, how are we, and that all the participants asked about examples. And I think it’s easier of examples of quality than good quality. So what’s poor quality software mean to us, it might mean the products don’t let us do the things we need to do. It might mean it doesn’t align well with our business processes and might mean that the products too hard to use or full of defects and crashes a lot, it doesn’t behave the way you expect to when you get surprised by what it does for security holes, there’s a lot of ways that you can encounter poor quality. Just last week, I installed the latest windows 10 update on my, on two of my PCs. Well, really Microsoft automatically installed those for me. Thank you very much. And both went to nearly 100% disc activity all the time, never had that problem before I spent hours trying to figure out what was going on.
Karl Wiegers 00:47:41 And that strikes me as a quality problem somewhere. So I don’t know about you, but I encounter products all the time that appear to be designed by someone who never used a product of that kind or has some other deficiencies. And that’s why I wrote, , my previous book, the thoughtless design of everyday things, which, you know, shows a lot of the kinds of places we can fall short on quality, even though I can’t give you a nice, concise definition of it, but I think each team needs to think about it and then figure out OK, based on what we think quality means today, what are we going to do to try to lay the foundation for that and ascertain when we’re there?
Gavin Henry 00:48:16 Yeah, I think I’ve got an example too, where quality could be again, what you’ve just said. It depends on what the requirement is, what the actual user thinks is important. So a, a product could get something done in half an hour with no, no errors is that quality. Or they could get it done with fi within five minutes with 95% success. You know that, yeah,
Karl Wiegers 00:48:39 That might be good enough, but you don’t know
Gavin Henry 00:48:41 Exactly. One that I found last week was a, an accountancy software application that we use online for years and we switched our payment processors. So the screen hasn’t, you know, the design, the layout of the page hasn’t changed, but the backend logic has obviously changed cause we’re using a new credit card provider, but it’s as if they’ve never tested it with someone saying in front of it. And I’m thinking about the book that you just said, I’ve seen that book before and you kind of gave me a copy where this is out in the public. And nobody’s actually sat down, put in their credit card details and tried to put in a different billing post code or zip code, like in, in America, it’s using the default one on their system. which might not be where the credit card statement gets into. You know, so it’s definitely, I was like, how could they have even done this? And someone do that, you know, and then support. Cause it comes down to the quality issue and oh, we’ll deal with that when it happens,
Karl Wiegers 00:49:37 Which no customer agrees with, no customer will ever agree with that attitude, but it’s
Gavin Henry 00:49:41 So I have to open a ticket or log into the system, change their main contact address because they want to pay for a credit card, which just, you know, reinforces everything you’ve explained for those lessons.
Karl Wiegers 00:49:51 And basically your conclusion is this is rubbish.
Gavin Henry 00:49:55 Think about it’s not good quality. It’s not good quality.
Karl Wiegers 00:49:58 It’s not good quality. And you know, another place I’ve encountered that is just in the course of my daily life is you’re sitting next to someone on an airplane or talking to the cashier in a store or talking to a neighbor. You would not believe how many people have said to me once they learn what I do for a living said, well, you wouldn’t believe this new system we have to use at work. I hate it. They clearly didn’t talk to anybody like me before they designed it. And that’s in the good argument for usage centered exploration of requirements and designs.
Gavin Henry 00:50:27 And that’s what you’ve just said. That’s the same thing that’s happened for the past 50 years.
Karl Wiegers 00:50:32 I know. And that’s the thing that’s so discouraging. So I know a guy who was one of he’s the guy I consider the father of requirements engineering. And I met him more than 20 years ago. And he told me at that time in, it was about five years ago. I knew his work, but I met him and he said, you know, he stopped teaching requirements classes because after 20 years he was still saying the same things to people, to whom it was all brand new. And he found that discouraging. And I’ve had the same kind of reaction because I’ve been teaching requirements classes now for about 25 years. And to me, it’s astonishing when I find people that are professional business analysts or developers or software engineers. And I’m talking about stuff that’s been known for a long time and they’ve never encountered it before. And they say, wow, what a cool idea. And that gets kind of discouraging. So I think there’s not been nearly as much progress in those aspects of software engineering. As there have in the more technical discouraging, all this on the does help keep books sort of viable for many years,
Gavin Henry 00:51:42 I’ve been doing programming for slightly over 20 years and you do see the same, same things come and go. That’s why I think software engineering on the show in journal is good because a lot of our things are timeless. Okay, I’m going to move us on to the last section of the show. Cause we’re, we’re doing well on time. Anyway, I’m calling this process improvement, particularly your less than 51 in your book watch out for and quotes management by business week. What does that mean?
Karl Wiegers 00:52:09 Well, business week, I think it’s called Bloomberg business week. Now, now was a magazine that what’s going on in the business world and technology, worlds and stuff. And here’s the scenario. I suppose there’s a senior manager for a software organization and he’s taken a flight or, you know, just searching around and he reads a magazine article or a blog post or a news item about some new software development or project management methodology that promises to bring great improvements in productivity. And the manager thinks, Hey, terrific, let’s do that. And all our problems are solved. So he goes back to work and says, we’re all going to do this new methodology because this is going to make things lot better for us. And that is the manager decides to jump on the bandwagon of whatever hot new approach people are talking about. And I think that’s a mistake. So that’s what I mean by avoiding management by business week,
Gavin Henry 00:52:57 I do that a DevOps email comes out on a Sunday. Oh, I always paste links into the group chat
Karl Wiegers 00:53:03
Gavin Henry 00:53:04 And we should look at that.
Karl Wiegers 00:53:05 Yeah. Yeah. And sharing information is great, but here’s what I think people ought to do with that. So let’s say it was DevOps. Okay. I use in the book, I use a example of a hypothetical method called method nine, you know, as the example here.
Gavin Henry 00:53:20 Oh, that sounds good. Let’s get a Twitter account for that.
Karl Wiegers 00:53:22 Yeah. Yeah. And that way we can I’ll be doing method nine, because what I’ve heard so far, it sounds fabulous. Right. But here’s what I recommend. Whenever an organization wants to achieve, let’s say better performance. However you define that productivity. Whatever. I think what you should start with is by asking yourselves, why are we not already achieving that better performance? In other words, do some root cause analysis of the issues that are preventing you from being as successful as you’d like to or understand the cause of some problem and root analysis is a simple technique that can really quickly and efficiently help you identify the real problem. And from that, you can identify approaches to address those specific causes that you think will lead to the improvements. And you might discover that method nine is not going to work because that doesn’t really address your root causes no matter how good it sounded and whatever you read, maybe it doesn’t help your breakdown. The barriers that are preventing you from being as successful as you want already. So let’s start with some root cause analysis first.
Gavin Henry 00:54:23 So how do you make time for that? If you have got a management structure or a manager that always feeds you, these new things, you know, doesn’t want to listen or doesn’t want to face the facts that things are wrong, is that an organizational issue or what suggestions you have for that type of scenario?
Karl Wiegers 00:54:40 Well, a couple of things, sometimes it’s an educational thing. I mean, there’s nothing wrong with being ignorant. We’re all ignorant about the vast majority of knowledge in the universe being stupid is another harder problem to deal with, but being ignorant. Okay. It’s a matter of recognizing what you don’t know and being willing to learn it. So one thing that we have to do is manage upward in a case like that. And that’s a matter of, of educating your managers because sometimes the people who are jumping on these bandwagons aren’t technical people, they don’t really understand the barriers, but if you’re in a position of being tasked to say, go buy method nine and we’re going to all you know, get trained and that’s what we’re going to do from now on. Then I think your responsibility then is to say, well, what is this going to do for us?
Karl Wiegers 00:55:22 And how do we know it’s going to do for us? Do that for us. In other words, have we done an analysis, like a root cause analysis to figure out what our current barriers are and be confident that this is going to help break them down. Maybe it will, but let’s do the analysis first. I’ve never just done whatever my manager told me to do. I want to make sure I understand what we’re doing. And sometimes I will try to explain to them why that is or isn’t the best thing to do. And maybe you go off and do a root cause analysis on your own even, and come back and say, well, we thought about what you said and here’s what we learned. Are you sure this is still what you want us to do? You might win. You might not.
Gavin Henry 00:55:58 Well, it sounds like some good advice. I’ve got a couple more questions before we start wrapping up. If I squeeze them in, let’s say let’s just go back to our project management section. Cause I really like the five dimensions of scope, schedule, budget, staff, and quality if we’ve got a struggling project. So one of those is way off or a couple of them they’re way off schedule or the got massive scope creep or over budget. Are there any quick wins that you could recommend for our struggling project like that?
Karl Wiegers 00:56:27 Well, if there were quick wins, it would always work. Then I would sell them and make a fortune and buy a very nice house somewhere. But I, I don’t think there’s any magic solutions, but I think you do have to get back to understanding why good example scope creep is a perennial problem with mini software projects where new functionality keeps coming along and people keep finding, well, we’ve got more to do than we thought we were going to have to do. And we’re running out of time, but none of these other things have changed. You know, we haven’t got more people. We haven’t got more money. We haven’t got more time. So how are we supposed to make that happen? Well, you can’t become more productive by decree or by swapping out your whole team for percentile people or something. You can’t do that.
Karl Wiegers 00:57:10 So I think you have to ask yourself, why are we experiencing this phenomenon? Are we bad at estimating? Did we not talk to the right users? Did we overlook some key stakeholders? And all of a sudden now we found them and their needs are coming in very often when you’re getting a lot of UN ongoing scope creep, as opposed to just normal kind of growth, there’s always growth and change. But if you find you’ve got incessant scope creep, you’re probably not doing a very good job on requirements elicitation. You’re probably missing things, maybe not asking the right questions, maybe focusing on features instead of usage, maybe not doing a good job of prioritization or maybe not doing a good job of defining the scope of what you’re trying to do. And then asking yourself when each change comes along, is this really in scope? You don’t just throw in on a story card and put it in your backlog and without doing some filtering first to it’s. So again, think understanding we’re experiencing that and thatís business objective helps you. How do respond to that?
Gavin Henry 00:58:12 Well, my last question, I think you’ve answered in that one would be what’s the most common issue you see? And it sounds to me like not doing the requirement stage is a pretty big one. Well,
Karl Wiegers 00:58:23 Yeah, that that’s a big one, but, but, you know, I used to years ago be involved with some formal software process improvement activities like with the capability maturity model or CMM when that was a big thing. And I used to joke because one of the things that was common with those kinds of activities was to do a formal process appraisal where people would come in, who were properly trained and authorized and do an appraisal of your organization to see how well you were doing with respect to the expectations of this improvement model and really kind of opened the Kimo and see what was happening. And I used to kind of joke that I could do a process assessment for an organization remotely for 100, I will send you a postcard and I will write your top three problem areas on that postcard. And those areas would always be requirements estimation and testing. And those are the areas that I think people had the most difficulty with. There are others, of course, and this is, you know, a little simplistic as a kind of a joke, but I suspect that those are still very common issues that software teams wrestle with. I donít know. What do you see? What are the kinds of things that people encounter in your experience that are chronic perennial challenges?
Gavin Henry 00:59:35 I think it’s pretty similar, you know, not getting maybe too excited about the project and cracking on too fast, not spending that time on their requirement stage sacrificing testing to just doing things in front of them, you know, and not actually automating those tests and using them as a safety net price standard thing. So you’ve explained that you’d be shocked to not think that they’d beat solve by now.
Karl Wiegers 00:59:56 Right. And you know, it’s kind of funny, there’s, there’s sort of a, an unstated mindset among people who are eager. I mean, people of course are eager to get into, you know, writing code. I mean, that’s what software engineers like to do is build systems and write code and all that. But there’s sort of a, an unstated undercurrent here that says we have to get started writing code right away, because it’s going to take us so long to fix it later. Well, maybe if we took an approach to think a little bit more and plan and explore, maybe you’re not going to have to fix so much of it later. So not only is that going to be cheaper, but it’s a lot less stressful and you can probably finish chunks of work quicker than you thought, because you’re not devoting so much of your effort to rework.
Karl Wiegers 01:00:38 That’s one of my big bugga boos is rework. I hate rework. I hate doing over something that was already done now. There’s always some of that for perfectly reasonable, legitimate reasons. But I think if most organizations took a look at measuring how much of our total effort is spent doing things over that maybe we didn’t have to do. If we had taken a different approach, sometimes you might find it. You could get a third of your bandwidth back. If you did take the time to do some of these other things that lay the foundation and iterate at the higher levels of abstractions instead of on releases. And I think you’d probably find that we come out ahead that way, most of the time, but it’s not as much fun as writing code.
Gavin Henry 01:01:17 Exactly. Obviously it’s very hard. If not impossible to distill 50 years of experience into one book, you’ve done a very good job, let alone one podcast episode. But if there was one thing a software engineer should remember from our show, what would you like that to be?
Karl Wiegers 01:01:33 That’s a good question. I tried to in this book to put in a lot of the things I’ve learned from, from a long time, and I guess one bottom line lesson is that I have never known, could I building as well as software could ever built. If you can’t say that, I think you should always be looking for ways to improve your processes and your practices. So the final lesson in the book cautions you can’t change everything at once. Both individuals and groups, organizations can only absorb change at a certain rate and still get their project work done. So you’ve asked a couple of times and how do you do this? How do you get time to do this in, in a busy project and stuff? And the answer is really, you just, you have to make the time to spend of your effort on improvement and growth and learning and change and experimenting cause otherwise there’s absolutely no reason to expect the next project to go any better than the last project.
Karl Wiegers 01:02:29 And one of the techniques that worked well for me is that on every project, I would try to identify one or two areas I wanted to get better at. It could be estimation or algorithm design or unit testing or whatever. And I’d spend some of my time on that project, learning about those techniques, looking for opportunities to apply them right away. And you take a small productivity hit every time you do that. It’s a learning curve and that there’s a price. But if I do that, then in the process, I’m going to improve my own capability for the rest of my career. So I encourage software engineers to adopt some kind of systematic learning philosophy, always be carving out a certain percentage of your project time and managers too, in the schedule, carve out a certain amount of time for learning how to do the next project better. I think that’s a, a real bottom line message.
Gavin Henry 01:03:18 Thank you. Was there anything we missed that you’d have liked me to ask or mention, or you’d like to mention now?
Karl Wiegers 01:03:24 Well, maybe just one point, you know, these are lessons I’ve learned and I think you shared some of those lessons where the things there that you said yes, I’ve learned that or, or no, that doesn’t apply to me. What was your reaction?
Gavin Henry 01:03:34 Yeah, my career’s less than half of yours. Some things did have a common theme, but other things were new to me. So I think, you know, a lot of people should spend more time reading all these books. There’s so much out there and there’s so much knowledge that flashes past us.
Karl Wiegers 01:03:50 There is. So you’ve been around a while. You’re not exactly a newbie. And so, you’ve accumulated your own lessons about how to do software development more effectively and more efficient. So, I’m hoping that everybody would take some time to think about their own lessons, to share those freely with their colleagues. Like I alluded to earlier, help the teams, put those lessons into practice, and also be receptive to the lessons that the people you work with have also learned. Basically, you don’t have time to make the same mistakes that every software engineer before you has already made. And that’s how I learned a lot of these things is by doing something that didn’t go so well and saying, what should I do differently? So I think you can bypass a lot of these painful learning curves, or at least flatten them out, by absorbing knowledge from people who have gone before, which is why I write books like this.
Gavin Henry 01:04:40 Excellent. My two lessons I’ve learned are: it’s always typos, and it’s always permissions — whether that’s security permission or, you know, business permissions. So, where can people find out more? Obviously you’re on LinkedIn, which I’ll put a link to in the show notes, if that’s OK. How can people get in touch if they want to learn more about your books, your courses, you know, professional consultancy, that type of thing?
Karl Wiegers 01:05:02 Well, my company name is Process Impact, and my business website is processimpact.com. My personal website is not surprisingly karlwiegers.com and there are links at both of those sites where people can send me messages. And there’s also links from those pages to other pages or websites that describe some of my books like Software Development Pearls, The Thoughtless Design of Everyday Things, Successful Business Analysis Consulting, and my forensic mystery novel that you mentioned at the beginning, The Reconstruction. It’s the only fiction I’ve written, and it was the most fun I ever had writing. I just had an incredibly cool idea for a novel. I said, yeah, I wonder if I can write fiction. And other than my PhD thesis, a long time ago, I hadn’t written any fiction. So I gave it a shot and it was just a blast and had a fun time doing that. So those websites are all accessible from process impact, or plus of course you can hear the songs at Karlwieger.com. If you dare.
Gavin Henry 01:05:58 Karl, thank you for coming on the show. It’s been a real pleasure. This is Gavin Henry for Software Engineering Radio. Thank you for listening.
[End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
