Hey, a quick message, for those of you who are listening to this episode on Spotify, I have a small favor to ask Spotify. Now allows mobile users to rate podcast, I would really appreciate it. If you can take a quick, pause to go to the technique Journal podcast page, and leave your favorite show. Your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot. Everybody wants to be more productive.
And if you're looking to acquire productivity either, as An individual or as a team isn't as great as you'd like one thing you might find is that you spend too much time on rework. A way to boost productivity then is to create high-quality software from the outset so that teams can spend less time on rework, both doing development and following release.
Hey everyone. My name is Henry Surya with Robin. And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal.
Hello my friends. Welcome back to the tekhelet Janelle podcast the show where you can learn about technical leadership and Excellence from my conversations with great thought, leaders in the tech industry, and this is the episode number 103. If this is your first time listening to Tech lead, you know, subscribe and follow the show on your podcast app and on LinkedIn, Twitter and Instagram. And if you'd like to support my journey creating this podcast, Subscribe as a patron at package.
You know, dot, f / Patron. My guest for today's episode is called uyghurs call is the author of software development pearls and the principal consultant at process impact in this episode called shared some lessons that he has learned over the past five Decades of his career or what he refers to.
As pearls we first discussed software requirement and its role for communication and why it is very important to define the rights of Requirements call then touch on the reasons why we cannot optimize All Quality attributes that we desire in a software and instead, advised how we should Define the quality attribute requirements. Next caller, shared some project management. Pearls related to work planning dealing with estimates and making commitments.
Towards the end, call explain the relation between quality and productivity using pain as a driver for improvement. And lastly, his out. Ultimate pearl of wisdom. I hope you enjoy listening to my conversation with call. If you find it useful. Please help. Share it with your friends and colleagues who can also benefit
from listening to this episode. It is my ultimate mission to spread this podcast to more people and I really appreciate your support in any way towards fulfilling my mission. Before we continue to the conversation, let's hear some words from our sponsor. Definitely is the top International software development conference, With an emphasis on coding, architecture and tag leadership skills.
The lineup for this year is truly stellar and features many Legends in software development names, such as Robert Uncle Bob, Martin can back Scott Hanselman, Franca subramanyam Carolyn honey, Alan Halep, Mary, poppendieck, and many other prominent names, including some of those who have also appeared in this podcast before the conference takes place online. So you can enjoy it from the comfort of your couch. Ouch, we spoke to the definite the organizers and I'm happy to
share that technology. You know, has got the 10% discount code for you. Enter the promo code, awsm underscore tlj. When you purchase the ticket on definite e.com, here's the promo code. One more time awsm underscore, tlj. Depending on the time when you purchase a ticket early price is still available. See you there. Today's episode is proudly sponsored by Skills.
Meta the global community and events platform with more than 100,000 software professionals here members, can organize their learning experiences around the technology topics. They care about most you get on-demand access to their latest content thought, leadership insights, as well as the exciting schedule of tech events running across all time zones. So we're the devops our data science is your bus or you are fan of functional programming or all things cloud.
What'd you can make real connections with people who share your interests head on over to skills method or calm to become part of the tech community that matters most to you. It's free to join and you will find it easy to keep up with the latest tech Trends. Hi everyone. Welcome again to the tech lead, you know, podcast today, I have with me, someone, I really looking forward to learn from him. His name is Carl. We goes is the principal consultant with process impact and he has written.
In books, 13 books. That's really a lot of books out there. And today, in particular, will be talking about his latest book, titled software development. Pearls, the subtitle is actually lessons from his 50 years of experience. So 50, that's really a lot of years out there. So yeah, counting so much for being in the show. I'm really looking forward to learning from you with all your posts in the book. Thank you, Henry. I'm happy to be with you today. So, call your book has 60
pearls, when I look at them. Um, it's really great but maybe before we start into those, can you maybe start by sharing your career Journey? Mentioning about highlights turning points Okay, I have a slightly unusual background, but the age group that I'm in a lot of people came into software from different backgrounds. We didn't have a lot of computer science, programs, or software engineering programs in college. So I first learned to program in Fortran.
Of course, back in college in 1970. It's hard to believe that was nearly 52 years ago, but it was, they didn't build a software right away. I actually have a PhD in organic chemistry, which I've always thought was the perfect background for anyone in it on. No. Not everyone seems to understand that, but one third of my PhD thesis was code. So I've done a lot of programming in a lot of different ways after graduate school and postdoc.
I began my career as a research scientist at Kodak in New York and one of the major turning points was around 1983, when I did switch over into doing software development full time for several reasons, but software had been my second interest anyway. And by then it was becoming my first interest. So I was a software developer at Kodak for several years and I managed a small Software group
in the Kodak research labs. And I moved more into business analysis, quality engineering, and process Improvement. And another major turning point came in 1996, when my first book was published, which was called creating a software engineering culture, and that was a lot of fun. I always wanted to write a book, but I really didn't have an idea but some ideas came together then and that turned into my first book. And then, another big Turning Point happened. A couple of years later.
I'm 1998, when I left Kodak and started my software development. Eating and training company process impact. Since then I have continued to write books periodically on various topics including requirements peer reviews project initiation Consulting, product design, and even a forensic mystery novel. But for the last 25 years, mostly I've been doing consulting and training, so maybe some other time you would cover your forensic novel.
But for today, we'll be covering about your software development pearls. As you mentioned in your career Journey, you've been dealing with a lot of different areas, right? It's not just purely soft. So you've moved into requirements design process Improvement culture. I think it's really great to see all these actually covered in the books as well.
So there's in total six areas if I'm not mistaken starting from like requirements design, project management culture and teamwork quality and process Improvement. We may not be able to cover all your 60 but I think we'll just take the importance one or interesting ones for you. So that's that with requirements.
I think this is very interesting and look at the different roles that you You have think we'll just focus first on the first thing, which is the overarching objective of requirement development is clear and effective communication. So tell us more about this because yeah, we know requirements should have a very clear and effective way of expressing the requirements of the software, but can you maybe
elaborate furthermore? Yeah, I always think of requirements as being all about communication software development is maybe half communication and half Computing
but All about communication. So I use the term business analyst to refer to whoever on a project, is responsible for Bridging the communication gap that always exists between the customer domain, whatever, kind of customers, or users you talking about in The implementer Domain, Whoever has to go off and then build some solution to meet some need or exploit some business opportunity. So, the ba is real.
It's not a title necessarily although many times it is, but it's a role in the central role of the be a, I think Is to facilitate exchanging knowledge about the requirements among all of the project participants. So it's a really critical bridging function and there's no single way to accomplish this. Communication, people use different kinds of names for
different kinds of information. If you're talking about user stories, in an agile world, if you're talking about, use cases, or functional requirements, more traditionally, it doesn't matter. My principal heater is that the developers need the same information to write the correct code properly. Regardless of what you call it, regardless of what development lifecycle you're following.
So, I don't think there's anything special about agile, requirements, and calling things by in special names. In fact, there's a lot of confusion over even what the terms used in requirements mean? So, I find that when I start talking with people about requirements, the very first thing I have to do is Define our terms so we can communicate effectively. For example, if I say business requirement different people have different ideas about what
that means. So immediately at a communication disadvantage, another problem that we have is that we have multiple audiences for requirements information who have different needs, they want to see information in different ways, we different levels of detail so the ba has to focus their requirements activities on getting a whole lot of information from various sources and presenting that in ways that let all these various audiences, get the information they need to
do their jobs, effectively and efficiently. There's two techniques that people sometimes seem to try for It's work, telepathy reading minds and Clairvoyance. Knowing thing is somehow magically, those don't work very well but they seem to be the technical foundation for some projects. I also have another philosophy when it comes to communication here, I think the cost of recording knowledge is small compared to the cost of
acquiring knowledge. And so sometimes people aren't very interested in recording information over. Don't have time to write that down or we don't need to write that down and I think that's a terrible mistake. Because human memories are imperfect, their transient the fallible. Have you ever had the experience Henry, where you've had a conversation or a meeting with some people? You walk out? You think you've agreed on something?
You think you have a common understanding and then a little bit later, you realize, oh, we interpreted something differently. We remembered something differently if you ever had that kind of experience. Yeah, almost all the time, especially in this remote work. So you have a sink, maybe you chat a little bit but yeah, turns out the understanding is actually very different and you don't know it's different course. You just go off and do your work thereafter in.
Good faith, based on what you thought you understood and someone else thought they understood something different. So I think having a group memory, a documented group memory by documenting requirements at an appropriate level of detail, gives you some shareable resource that can
persist over time. And even if you did all have the same understanding, when you walk out of that discussion or meeting the most part, you're going to remember in six months when you have to go back and say now what were we doing here? Or I got to fix that or somebody requested a change? So So sure documentation can get out of date. No question. It takes some effort to maintain it. No question. But I think a shareable group memory is the phrase.
I like to use for that is a valuable asset to have and then it's up to the be a to work with their various stakeholders and audiences to figure out. Well, what's the best way to represent knowledge to meet your needs? When I talk about writing requirements, I'm mentally translate that into representing requirements knowledge. Sure, natural language. Text is the most common But you can draw lots of kinds of pictures visual analysis models.
We can use tables or prototypes, or photographs, or mathematical Expressions. Some people want all the details other people just want a high level view so the goal of trying to figure out how do we communicate all that knowledge. Clearly and accurately that's really the essence of requirements work. I think I like the two techniques that you mentioned telepathy and Clairvoyance. I think in the Practical world this is what tends to happen again especially in the remote work live.
You don't actually sits Side by side. Yeah, maybe you have a saying, you kind of like talk about it and then, okay, people just split and do their own works and actually they don't think very often. So sometimes this miscommunication happened, maybe when you have a particular Edge case, you don't want to ask because you're afraid that person is busy or whatever that is. So I think that tends to be a lot of this unclear and an effective communication
happening. And I think one of the particular important things that you mentioned as well, it doesn't matter if you have a very great team who can implement the code in the best way. But if they're doing the requirements wrong, they are probably most probably building the wrong thing. So, tell us more about this cause of not having a good requirement and someone implementing it the best way they can. Yeah, that's a real source of
inefficiency. I believe, everybody's working in. Good faith. They're trying to do the best job, they can based on their
knowledge and their assumptions. Are you touched on an important Point like an edge case, where maybe it's something comes up as you're implementing a particular capability and you think of an exception that That we haven't talked about or you think of a particular as you say Edge case that we haven't discussed how to handle that, you have to make some assumptions, then we have to go chase down the information and somebody might be busy or not available or in a different time zone.
Like you admire what 19 times harsh something right now it's hard to reach people sometimes and so you make assumptions you make guesses and you might have to go back and fix it. And that's the problem. Because anytime you have to go back and redo something, anytime you have to fix something because Of a misunderstanding or a piece of knowledge, you didn't have or something that changed that's rework.
And we work as expensive or simply just having errors and working in beings, we're going to make mistakes and we're going to write something wrong or we're going to be ambiguous in the way we say something and people interpret it differently from what we meant. So then you have to go fix it later. Well anytime there's an error, the quicker, you can find that error and fix it. The less work you have to do to fix that, that's why.
It's so important to I think do, for example, peer reviews of requirements. I think the highest leverage quality practice that software has available is effective, peer reviews, of requirements documents, because errors that you find before someone wrote code are cheaper to fix than afterward. No matter what life cycle, you're following or how quickly you doing it. If you have to write the code twice that costs, you more than
if you have to write it once. So that's why I think it's so important to not necessarily try to perfect the requirements but How to get them better than just some vague conversation and hope people can go fill in the blanks without any confusion or errors.
So, I also notice this kind of research when you find the errors closer to the right side in the value, stream mapping way in the production, especially it costs like really exponentially expensive rather than you do it in the more towards the left, that's why this term called shift left. You try to reduce the error from the beginning. Thanks for sharing that. So you mentioned something about explaining about the key terms. Some people refer Were to it as
the domain, right? So, the domain terms domain driven design, why having this shared understanding? Maybe be the terms, maybe be the calculation. Whatever is actually very important for any business analyst the product manager and also development. It is that's why we need the tools that I think is a good idea is to Simply create a glossary of terms.
I was working with a client once and I was really a requirement specification and they were planning to Outsource the development of this particular product. So obviously This because when you're Outsourcing something, you know basically mailing a requirements spec or something over to other people to do then it has to be better than if you're sitting down side by side with someone where you can talk about issues as they come up and fill in the gaps.
So I was reviewing this for them and I found there were two terms that they were using that. I thought might mean the same thing but I wasn't sure and it turned out. Yes, those mean exactly the same thing in that case. Let's just pick one term and stick to it so that people don't
have to mentally. Late. It will wonder if they're different because every time you do something like that, we're using synonyms or things that are close, but maybe not quite the same or terms that mean the same thing or mean different things. Rather say, in the business domain versus your technical world. Every time somebody counters one of those they have to try to figure out. Okay exactly. What does this mean? I'm not sure I'd better ask somebody or I'll make a guess.
All of those approaches are less ideal than just having a common vocabulary and understanding to minimize some of those miscommunication. And we'll see if led the development team treated as two different things, they write it in two different variables or two different concepts in the code. The next person who comes again like what is this and build on top of that? So in the end, I think you have a very fun Wild Way of expressing the requirements. In the software itself, in two
ways, as two different things. And then somebody else comes along and says, we can just refactor. This looks like the same thing to me, let's just be factored into one. Maybe they really were different and you can't combine them, and then you have a problem. This is what happens when people are Hasting. Sometimes they don't want to take the time to do this, they want to get to the real work of coding. And I think thinking is a part of the problem or part of the
solution really. It's an important part of what we go through and not everything in software is got to be code, thinking can save you writing the wrong code, or writing the code more than once. Thanks for covering this requirement. But let's move on to the design. When we mention about coding, of course, design is one thing, right? One of the things that you highlighted to me is that you Can't optimize all desirable quality attributes. So I think quality attributes.
Some people call it non-functional requirements or these kind of terms. So tell us more about why we can't optimize All Quality attributes? Yeah, I think that's a real important Point. There's functional requirements and there's non-functional requirements. Some people don't like the term non-functional because it doesn't tell you what it is.
It tells you what it is and I think quality attributes is what people are normally thinking of, when they say non-functional requirements, it's really a lot of different dimensions. Quality. There's no single measure of quality. That tells people everything they need to know about the quality of our product or what
quality they want to see. Some of these quality attributes are extra invisible to users like usability, reliability, security, robustness and others relate more to the products. Internal qualities such as portability or maintainability of verifiability. But the reason you can't optimize all of those is because there are a lot of different kinds of relationships between them. So sometimes, When you increase one of those desirable attributes, it increases another one.
That's good. If you increase reliability, you're going to increase availability because the software is not going to crash as much, but if you increase other things that might decrease a different attribute and I think a good example is around security, I think we'll all agree. That multi-factor authentication is more secure than just using a simple login password, but there's a usability penalty. You pay for that because now the user has to Multiple steps. Maybe take more time.
Certainly take more time and might need multiple devices to login. Sometimes, I've had to use my phone so I can watch certain shows on streaming TV. I understand the security but it's a little silly and it's clumsy. So you have a usability, you reduce usability, because your increase in security, and then other attributes don't have much of a connection. But even here then certain quality attribute, they can be very complex with multiple Dimensions.
So like usability includes both ease of learning. Any and ease of use. So if you optimize the design for ease of learning by new users or occasional users, that might make the system frustrating to use for experts, because it slows them down waiting through menus, instead of being able to do something in the command line interface. So you have to balance those different quality attributes
against each other. And that means you need to do enough requirements elicitation around those aspects of the requirements that you understand, which of those Dimensions are most aligned with achieving our business objectives, which ones are most important to our most important
customer classes. For example, it's a really just have to decide what does quality mean to your key stakeholders and then align, everyone's work towards those objectives and if you don't do that, if you don't specify the details of these desired quality characteristics. If you don't prioritize them so that the designers can make appropriate trade-off decisions. Then you're just lucky. If you get whatever quality, you hope to see in the The final product.
So thanks for highlighting all these different trade off balance. Sometimes when you increase one cruelty, attribute the app you may be lucky the increases the others, but most of the times it actually reduces the other side is like an opposite effect kind of thing. If we can tie this to the requirements back, how do you specify these quality attributes? In the requirements? Sometimes, stakeholders product people. They just sell.
Yeah. You just built to the best quality because they are really not aware of what cruelty attribute to think about or maybe they're just too many of them. So this ellipses, right people call it till it is s so many realities of death. How shall we actually document this properly in the requirements itself? So that is clear. It's effective, that's an excellent question.
Henry anyway, the users will not usually spontaneously tell you what their quality expectations are they sort of have passed it ones that they haven't stated. And so part of the business analyst job is to start those conversations. So we can make that a part of our exploration of requirements during elicitation. The other thing that will happen is even if it comes up in the conversation, you're likely to get a very simplistic answers. So you can't ask a question.
Like, what are your availability requirements? Probably, nobody knows exactly what you're looking for. How to answer that question? Or they'll say systems got to be available. Anytime somebody wants to use it, isn't that obvious, but that doesn't really help you very much. So a b, a has to ask more subtle questions, more direct questions, at aspects of it. Like are there certain parts of the system that it's more important to be available? All the time versus others.
Okay, well, that'll give you an idea of priorities, for things. Also, for example, if we have a system that requires periodic maintenance, I mean, sometimes I try to log into a website. It's like sorry, we're busy right now. Fixing something or doing our weekly maintenance, you can't get in. Well, how long can you do that? But time windows, can you use for scheduled downtime?
So by asking those kinds of more specific questions rather than very general questions, you know, if you ask a user what are your interoperability? Quirements they haven't got the foggiest idea what you're talking about, but if you ask them, are there other systems you have to exchange data. With our, you have to import data, from any place to do your job at the system, that might give you some information, that is in the category of interoperability, but you didn't
have to even use that word. So, the key thing that I took these that ask good questions and always try to subtly dig deeper and deeper. Most of the times we do it for the functional part. So we asked to create how the feature should be. How does it work? What are the inputs? What Output. But not the same emphasis is taken for this. Non functional attributes of a quality attributes. So I think this is very important as good questions and
always try to dig deeper users. Obviously they'll just do you know the best quality. As you can buy me know, that best is subjective right? It's contextual depends on the situation and depends on who you're asking. That's correct. So after we move to this design, let's move to the actual work itself. You categorize this as project management. We have the requirements we have. The design we have all these. So now time to execute. So one of the problems that you have is you set work.
Plans must account for friction. So tell us more. What do you mean by friction? Why should we account for it? Alright, so here, I'm talking about project friction not interpersonal, friction. That's a whole nother problem that we're not going to talk about, but it's a very real problem, sometimes by fiction. Let me give you a good example. I was in a software team shortly before I went off on my own as a consultant and I heard a conversation.
In between the manager and one of the people in my group that particular team member was providing a specific service to a project and the manager asked her. How much time are you spending on that particular service each week? And she said, eight hours for this project and he said, okay that means you can work on five of them at once then because 5 times 8 is 40 which is a nominal work week for many places even if nobody really works. The move hours, that's what it is on paper.
So that manager was making some assumptions. Is that we're not valid. The problem is, when you start getting people, multitasking like that, you haven't efficiencies because people don't really multitask. The task switch and just like a computer. If your task switching too much, because you're running too many things at once. It starts slowing down just because there's in efficiencies associated with the process of switching tasks, where there's dead time.
Basically what happens is that maybe this woman could do her eight hours for this one project and it's time to move to the next one. You don't just snap into a new way of thinking for that next project. It takes you a while to get everything in your brain, get all of your work materials in front of you, open all the right files so that you are ready to then be productive.
It takes time, just a little bit and you brain probably is that the more things you're working on at once the more time you lose to task switching overhead. And that's why extensively multitasking. People are not nearly as productive as you think. They're going to be. They just don't have as many A effective hours per week as it seems like there ought to be. It's just the way people work kind of related to that is the mindset you've had this
experience. I'm sure Henry, all software people have where you get into a state of flow and that's what happens when you're working on something and you're really productive, you're making great progress, you having a good time. All of a sudden you look up and realize oh I forgot to eat lunch because I was really cranking
along. He said that experience, I'm sure and so what happens if that state of flow gets interrupted you're working on. Like that and then you get a phone call or text message and like Pavlov's dog. We all check the phone immediately and see what the message is about. Or somebody calls you, the question, what happens to you when you're in that kind of mode? You know what I'm talking about, right? Definitely. I mean, I will brain work smartly, right?
So when you have this Interruption, especially when you think it's urgent, you kind of like wipe the whole thing in your brain and do the more urgent task, maybe you pick it up and then your contacts all change. But then when you have to go back to the floor, State. I think it takes a while. So the booting time is not as straightforward. Now. That's absolutely right. People have measured that and it can take like, 15 minutes or something.
To get back to where you were. Some people are better at multitasking than others. I don't know if I just have a short attention span or what, but, I'm pretty good at switching back and forth between things. I'm working on something for a little bit, then coming back and doing something else. When I was a manager of a software group, I had a guy who is not as productive, as he could have been a should have been.
He was very bright, very creative but he Couldn't put work out the door as fast as I thought he should. So, one of the things that we tried was having him block out chunks of time, try to eliminate some of this Interruption driven flow loss, so that you get longer periods of productive work. And then actually work pretty well. There really is, basically, you
don't deal with emails. You don't answer the phone for the morning, you can do that in the afternoon and get caught up in all the trivial things that you have to do. But if you block out your time so that you get bigger chunks of an interrupted work then, You're more productive.
So that's I think the biggest source of friction and what that turns into when it comes to project management as the manager, or even as a team member, you need to figure out what's your number of effective project hours per week on average and use that number for estimating. And for planning, instead of trying to say, okay, I got 40 hours to work this week. What am I going to do? Because you don't have 40 hours, you just don't.
Yes. I you don't account for sure like full 8 hours a day because we chat we take coffee breaks. C and F and I think what you mentioned speaks True to this concept called lean. So limiting your work in progress done multitask too much unplanned work as well.
If you have interruptions that's kind of like unplanned work, maybe incidents on call or maybe some managers asking about certain things in Urgent. And I think another friction if I make guesses about dependency where you are, depending on some people or team or maybe some kind of work that has to be there, but it's not available. Is it also counted as one of The friction in the project that you have to account. Yeah, that would be really a matter of creating rate states
where you're thinking, okay? I have to do these things. And as you point out, there are dependencies, I need this piece of information where I need all module that. Somebody else was writing that has to be available before I can integrate it with my modules. If it's not there, then you can't finish your task. So I think it's important to recognize those dependencies and build some slack time into your schedules to account for the possibility that not.
Everything is going to Exactly, like clockwork to get a little
depend on the work environment. Because, for example, if you're in a situation where you're not only working on a new product, but you're maintaining a previous product or you have to go back and fix something from previous iteration, those kinds of interruptions have to be planned for because that's another form of friction that's going to slow you down and you didn't plan for it. But you know that maybe on average, I'm going to have five hours a week that I have to deal
with those kinds of things. So, take all of that out of You're planning for how you're going to turn physical work hours into calendar time. Speaking about effective Alice, giving estimations, project management. Sometimes it's all about estimating, right? You have these two very interesting pearls about estimation, which I'll read it here. Don't give anyone an estimate off the top of your head. And the other one is based on what the recipient wants to
hear. So I think software developer most guilty of giving estimates, right of the top of the mind and also what She the requester ones here. So tell us more about why this is not the right way I guess symmetrical. Best guess as to what's going to happen in the future based on what, you know, and some
assumptions. So maybe you're walking down the hall and you run into one of your customers who says, hey, I've got an idea for some feature, I want to add to the thing you're working on now, so they tell you their idea and you say, yeah, I think we can work that in. That's not too bad. Sure no problem. So then you go back to your office and start thinking about it. And the more you think about it, the bigger it gets, There's all these hidden connections is all
these Ripple effects. It was all these other obvious depth of details and then you realize that maybe it's actually the opposite of what someone else agreed to do for a different customer the day before. So, it gets bigger and bigger. But when you told the person the bumped into the Hall, sure we can do this in three days, that was an estimate. Maybe off the top of your head, based on what you knew at the time, but it sounded like a commitment to the person who heard it.
They don't necessarily know the difference between a commitment and an estimate So I think the best answer for any requests about an estimate is to say, let me get back to you on that instead of just giving them an estimate, based on very little analysis and information, get the information go, think about it. Do a more careful job of thinking about what it's going to take to do that, then offer
an estimate. Also, if you give a point estimate like okay, that's going to take 40 hours, you can't predict the future that accurately. We might be better off saying. I think it will take between 30 and 50 hours. The problem is people don't like that managers in particular people who have to write the check or allocate resources, they don't like that kind of fuzziness but that's the reality.
And I always tell people in my classes, I'm not always crazy about reality but it's all I've got so I have to work with it and the reality is we can't predict these things precisely. So I think giving estimates in the form of a range is better. So that's the kind of my point about the idea of not giving people estimates off the top of your head.
So there's the other Rule that says you estimate you give someone should not depend on what you think they want to hear you mentioned that one as well and I can tell you a story about that. So I saw a conversation between a project leader and a senior manager, senior manager asks, how long is it going to take you to do this project project manager said about two years and the senior manager said no that's too long. I need it in six months. So what did the project manager? Say okay.
Well what changed in those seconds, you know he didn't get Or times as productive, he didn't get more people, the problem didn't get four times smaller, none of those things happened, he just said, okay, well you want in six months so I'll say I can do that. That's just a lie. Basically. I think knowing that someone's not happy with your estimate should lead to a conversation. Should lead to negotiation and say, okay, what knobs can we
turn to make this happen? Maybe my estimates wrong, but was you estimate, how did you come up with your estimate of six months them? See your manager? Did not have an estimate of six. See our goal, the project manager. In this case didn't have an estimate either, he had a guess. So if you're guessing you're going won't match. We're going to have to work that out but I think actually doing an analytical estimate based on some thought process, some historical data.
Some depth of understanding is going to let you compare. The differences may be in assumptions that you're making the, don't just change it because someone doesn't like it, that doesn't change the future. If I want to go on a picnic tomorrow and someone tells me it's going to rain. I can't just say, oh well, I don't want it to rain. Yeah, I don't, that's simply change the future, right?
Thanks for explaining these two different perspectives, because sometimes managers or leaders have their own goals and the software development. All we have is guess, we don't actually know unless we have done it before. It's like a repetitive work. We know the gist of the work but they are most of the time we just guess which brings us to the next Pearl, which actually is an extension of this problem. So you have given a range of an estimate, maybe one month to
three months. Obviously, man. Just don't like that kind of ambiguity. This like a big brains anyway, and they're kind of like, put pressure this often happens. I'm sure it's everywhere. They'll put pressure, but your poll says that no matter how much pressure others exert, never make a commitment. You cannot fulfill. Okay. This is very tough, but tell us more about this thing. I think I remember this and that's actually Point. Let me back up just a bit. These portals didn't come to me
on stone tablets or anything. These are things that I just learned over my career either. Sure from my personal experiences or from clients that I've worked with or from things that I've read and heard from other people. So I just accumulated these little bits of knowledge that I found helpful and relevant. The reason I wrote this book was to try to share some of those with other people because you've probably noticed that experience is a great teacher but it's also
painful and slow. And we learn a lot from mistakes that we made. I wrote this book so that people maybe don't have to make all the same mistakes that I made. And I've seen other people make one. The stories. I think that applies. In this case how did I learn this lesson about? Never making a commitment. You can't fulfill. So one time I was leading a process Improvement effort in a division of about 450 software and systems engineers and a big
company, usually very organized. Systematic process Improvement, thing back. When those were very fashionable, me and my manager had a meeting with the senior manager of this division, who is like, total levels above me on the organization chart, you wanted to know what was our plan for achieving a specific goal. Goal with this big initiative. So I told them how long I thought it was going to take us to achieve that goal. And he was one of these guys had. No, that's too long I wanted
sooner. He's the kind of manager and little lot of managers like this, who will say, don't tell me you can't do it. Tell me what I have to do to enable you to do it. And that sounds very collaborative. But in fact, it really wasn't in this case. So I explained to him how we came up with our estimates by looking at, with other companies had done with the similar approach and stuff and you know, Really pressuring me to commit to doing this goal in six
months. When I knew that, there was absolutely no way we could do that. So, finally I said, said I'm not going to commit to that and you just kind of looked at me I don't think anybody had ever said that to him before. He didn't really know what to say. No, I was wearing nervous telling this guy, all these levels up above me that I couldn't commit to what he was requesting.
But I knew that no matter how hard we worked, no matter how smoothly things went, it's simply could not happen in six months, it just wasn't doing Abel. So I told him I couldn't do it. So he said, okay, you're not going to commit well. Now, what? So we talked about it, we negotiated some, and he eventually agreed to the schedule that I had proposed to him. Once I explain how we came up with that, but my boss who was with me in the meeting, he was a
little nervous. He went back saying Carl told Fred, he wasn't going to commit, but I think that's the right thing to do, don't you? I mean, if you can't do it, what value is served by telling someone that you will, I don't think that accomplishes anything other than temporarily. Is someone feel better and you feel worse?
I think it also goes back to the psychological safety, this term being discussed a lot these days if you don't have psychological safety in the team, when the manager pressures you a, of course you will say okay for the sake of my job, just make that commitment at that point in time and you have to make that choice if it comes down to lying or promising something that you almost certainly can't do and might burn yourself out in the
process. If it comes down to that, we're losing a job but you might actually enjoy Oi, you have to decide, what are you willing to do for that? But my personal philosophy is to under commit and over-deliver,
to me that works. It's not as aggressive as what some people might do. But on the other hand be unreliable, if you ask me to do something and I tell you what, I'm going to have it done, it's going to be done by then you can count on that and I think that's maybe better than saying, what is it? What is it? You said you'd be bunting. You, why aren't you done? In fact, maybe if you said ok I'm not going to commit on that.
Some sneaky leaders might find another Then who will make that commitment, and he will say, okay, this person say, actually can be done. So then now you're in a like that, I'm a phenomenal, it's called the best liar wins. This is speaking about all these, as the main and trying to come up with the agreement on the timeline and all that, some people tend to associate time, spent on the effort and the
quality. So if you want to reduce time, okay, let's just reduce the quality but actually your next Pearl. Your next category of the Pearl is about quality and one of the things that you highlighted is about high quality naturally leads to higher productivity. So tell us about this quality thing because it's always put as a lever that you can play, right?
In fact, one of the classic things that shows up in project management is the Iron Triangle. You heard of the Iron Triangle or the triple constraint, is the other term that used for that. It's shown in various ways but it basically boils down to what do you want? Good fast or cheap pick to recognizing that there are trade-offs. And you just said, well, okay, you wanted faster I can That you care if it works well because if I go too fast, then I may have
enough problems. But it doesn't work. How good is that? But the problem here is that everybody wants to be more productive. And if you're looking to acquire productivity, either as an individual, or as a team isn't, as great as you'd like, one thing you might find, is that you spend too much time on
rework. My mission Bree work earlier and that just is a productivity killer teams plan to get a certain amount of work done in a particular time, but then they have to fix problems found in Heated work or maybe reallocate effort to repair a production system, a way to boost productivity then is to create high-quality software from the outset so that teams can spend less time on rework, both doing development and following reliefs.
I'm going to so long time ago I was actually in junior high school in which shop my really first will project, we have this chunk of wood and we had to just use various tools on a drill holes, cut it to size that sort of thing. And if you got it too small or put the hole in the wrong place, you have to get a new chunk of wood. Start over took me nine tries before I finally got it, right? And I noticed that one of the kids in the class got it, right?
And just two tries and he was done before me. He was going slower and more carefully. He wasn't making mistakes and so he didn't have to keep starting over and fixing it. So that's a lesson. I've learned a long time ago, so I hate rude work. I hate doing something over that. I've already done once some of it's unavoidable, it's the nature of what we do that. I think we just sort of accept
it as a normal part of software. Development and we don't really focus on it as I leave her as you said for increasing productivity and not having to fix stuff organizations. That do track how much of their portal software effort goes into rework can get some very scary numbers sometimes up to 40 or 50 percent of their total effort is doing things over there were already done once and that's why I think it's so important. As you put it out earlier to push, quality, to the left.
Let's try to find problems earlier and quicker because that Means we can fix them cheaper and not have to spend so much. We work later on. Have you ever worked in an organization where people measured rework our thought of it as an explicit thing? It's pretty rare, very rare to have this kind of measurement and maybe we can use the analogy of the number of bugs found. Yeah, it's probably not the same
thing, right? Yeah, certainly related because that's where the reward comes from, but I think the thing we want to try to do, is to minimize avoidable rework. There's always going to be some people are Are doing knowledge work. Human communication is imperfect. We can't predict the future perfectly, but I think if we improve our initial work quality, we can minimize the avoidable reword.
One of the ways we can make this more visible is to, you know, our project planning call-out rework as a discrete tasks. A lot of times you might say, okay, we're going to do this and we're going to build something and we're going to integrate it. And then we're going to test it and we're going to move on. Well that's never been my experience. My experience has been you build it, you Did you test it?
Then you fix some stuff then they re test it and eventually you know, Ron. But we sort of barely rework is part of that quality control. Activity of testing a review. I think it's better to make it a specific explicit task and then you can actually measure how much time did we spend fixing things after the test or fixing things because of problems found during a peer review? And that gives you an idea of how much rework you're actually doing and then you can ask
yourselves. Is that acceptable? Is that reasonable? All amount of our effort or should we say that's too much. Let's try to find some ways to cut down on our rework. Now, I do that in a group once we actually measured for several years, how we spent time on projects, how much time on requirements work in design and coding, and testing and maintenance and so forth.
We didn't like our initial levels of bug fixing and so we focused on techniques that could help us do a better job of producing initial high quality software within about six to eight months. We reduced our defect correction Works from 13 and a half percent of our initial work to do
percent which I was perfectly. Okay with, there's always some but 32 is higher than I liked so I think making that visible making it explicit trying to measure it then at least let you know what's going on. So you can decide is there some way that we can do, a better job of initial quality to do less rework. So these also comes back the lean principle that you have value stream, mapping. And maybe you will Analyze This, Wait times and also reworked.
So that's actually one part of the value stream mapping. Sighs and you are reducing waste. We all agree that we should reduce more ways more rework. But I think I just want to highlight one at the Pearl that you have about this is that organizations never have time to build software. So we never build software, but we always find the resources and time to fix it later. I think that's one thing for us to ponder about.
So let's move on to the process Improvement, you mention, if we want to improve the best motivation for changing, how we work is pain? I think some people learn from the hard lessons, so they Asthma. But this pain they do I think that's true life. In general, the best motivation for changing anything we do is pain which can come in many forms.
And here, I'm talking about the real pain that happens on projects because of quality problems or process, shortcomings or communication problems. Those kinds of things. I'm not talking about artificial pain, that's externally induced by managers or customers who are demanding the impossible, that can be painful, but that's not in itself. Terribly motivating.
Some examples of project pane that can be motivating are failing to meet delivery schedules releasing products that have more defects than you think are acceptable or missing functionality, delivering products that don't satisfy the customer needs. Or maybe you got burned by risks because nobody fought about the risks and figured out, how can we mitigate that risk and then turned into a problem and you
paid some price for that. So from your experience, those kinds of pain that should make you say, oh that wasn't very much fun. What can we do differently? Time to try to avoid that unpleasant situation. And so that to me is the driver for process Improvement. Give an example, I worked in the Kodak.com group. Kodak used to be a very large company. Now, it's not such a big company in the late 1990s.
I was in the Kodak.com group that ran all their websites and they had a configuration management problem. At that time, they had two web servers that were almost but not quite duplicates. They were having all these configuration management confused. Asians because it won't too sure exactly what to trust. What was most current at any time. They also had a huge backlog of change requests because there was a lot of people wanting websites at that point.
So I was there in a process Improvement leadership role and I helped introduce a change request system and better configuration management practices that reduce the pain coming from that. And the thing I found is that in this group which are bunch of very smart people, working very hard, very fast, sort of the Leading Edge, kind of stuff now the Very receptive to both process changes. A lot of times people and fast-moving groups are.
We're not interested in process, we don't have time for process, but they felt the pain and they saw the benefits they understood. That the process is always talking about. We're barriers to getting work done, they were structures to help you get the work done better and they saw that they were very receptive to it and it really made a difference in helping them manage. All this work that they were trying to do.
So I think if you're trying to get people to change what they're doing and they're all Busy working on their projects, then you have to make this pain visible. So that the promise of reducing the pain, outweighs the discomfort of making the changes because making changes isn't that much fun? No matter what we're doing, whether you're trying to lose weight or can prove your diet or create yourself for productivity. It's never fun but you sort of have to do it.
One of the problems is and curious if you've run into this that some of these kinds of project paint aren't always visible to everyone who's affected by it. So maybe a development team. Is taking certain approaches and that causes problems for whoever has to maintain the software later on. But that doesn't have a feedback loop back to the development team. So they may not even know that what they're doing is causing problems. Have you ever seen a situation
like that? Yeah, this is the syndrome. Like, we always done it this way so sometimes you are into the things, you never see it like a fish in the water so to speak. So you never know that. I could you live in the water, you live with the pain, but yeah, you need to take a step out and find the big picture. Okay. These are the paintings that we have. Yeah, but sometimes when we are in the Gs of making things, work and implementing stuff quick, we don't always realize this pains.
I think if you're in a leadership role, trying to steal an organization to better ways of working, you want to look for the points of pain, because those are the things that people can usually agree upon once. They are made aware of them. That, yeah, we can do better than that. That isn't that much, fun? Let's find some better ways to do our work. One of the other things, another podcast episode that I have with giardina London, she also mentioned about this making changes.
You want to ask people to change, you better stop the pain. First from bleeding more, right? Sometimes when we all introduced this change management, you just introduce more tactics more strategies but you actually not necessarily fixing the pain that the team is currently having. So you're introducing more pain. So to speak, there's always a
learning curve. You go through whenever you're trying to do something new or different, there's a learning curve for you take an immediate productivity hit as soon as you the take a class or you adopts a new methodology or Or you buy some new tool or whatever you're doing this different immediately, you have a productivity penalty because you have to figure out Lorraine. How does this work?
How do I apply it in my world and it takes you some fumbling around but then eventually if you can push through that, you'll get to a point where you're being more productive and hopefully less pain with the new technique, but the change itself can be unpleasant, people have to recognize that there's a short-term performance penalty, in our work. While we're going through that transition. This is a good segue to summarize, all the pearls,
right? The ultimate Purl, the Purl, number 60, so there are 60 of them. The last one you mentioned that you can't change everything at once. I think people know about this, but sometimes they live in fantasy. They want to change everything all at once. So tell us more about this. It's interesting because sometimes you do have groups and I've worked with some like this, that were very enthusiastic about process Improvement. The really saw the benefits of making improvements in whatever
areas working as well. For them. And I remember a group once with, about 20 people in the team who's like, that, they decided to work on seven different change initiatives at once, but the problem was they were spread too thin and they didn't really make much progress on any one of them. It wasn't clear, which were the top priorities. Let's do this first, let's do that next. And so they just try to do them all at once. Kind of a broad front strategy
as a result. They didn't make much progress which is frustrating. You I think you only get two tries in an organization to make Kind of changes that fail and then people aren't interested anymore. It's like I guess we can't do this. So I think what's important is to focus your change efforts on the places where you're going to get the maximum benefit for the investment of effort to make the changes and there's an operative
term. That I learned a long time ago that I love about process Improvement, which is gentle. Pressure relentlessly applied. In other words, you should all as individuals, as teens as organizations, you should always be spending part of your time learning. Knowing how to do things better. I've never known anyone who could honestly say, I am building software today as well as software could ever be built. I certainly can't say that. I don't know anyone who could, and if you can't, then you
should say. All right, let me try to find better ways. Let me always spend some of my time trying to improve the way I do my work in one way or another. So related to that is the idea of doing team retrospectives. This is a Hot Topic in the agile World which I think is great because retrospectives are such an important learning. D for groups to say, alright, let's reflect on what happened? How did it go or what parts went? Well, let's do that again.
But Parts didn't go so. Well, unless that we about blaming people, that's not the point. But let's just learn. Let's try to see if we could do those better. The next time, what happened that? We still don't understand. There's some learning opportunities there. What happened? That surprised us. Maybe some risks came up. We haven't thought about before, so you add those to your risk list. So on the next project, you ask yourself, could that happen again? So a retrospective is an Silent
learning opportunity. That helps, you kind of gently try to keep changing things just a little bit at a time. Thanks for emphasizing this. I think focus is really key, no matter whether in project. So in your individual life Focus, this definitely one thing that I think, modern people, right? We have this problem of focusing, that's just too many things to consume, the many things to learn, too many things to watch and whatever that things. So, thanks for sharing this one
of the problems with the focus. We also busy, we're working on so many things. There's so much pressure, everybody. Things yesterday is that if you don't take the time to learn and improve, you have absolutely no reason to expect the next project to go better than the current project you can hope but you have no reason to believe that's going to happen. So it's a magic if you expect that to happen by itself. So thanks call. It's been a pleasure talking about all these bills.
So for people who want to learn more about the other Pros as 60 of them, like I said, there are Lessons Learned by Carl in his 50 years of software development experience. So really were Earth to check. Because I mean, where else can you find this 50 years of experience? Dance into one book then you don't have to repeat the same mistakes? I think that's the benefit of reading this book so that you don't actually redo the mistakes that may be called it in his previous work.
So called due to time. Unfortunately, we have to wrap up pretty soon but normally Before I Let You Go. I have one last question that I always ask to all my guests which is to share this thing called three technical leadership wisdom. So think of it like an advice that you want to give to listeners out there so that they can Reflect and maybe do it better for their own sake.
Okay, well you could have led right into that, with your final comments there about ballooning from what we've done before. And the way I think about it is that you don't have time to ReDiscover everything that all the software people before you have already learned. So I think it's important for people to read the literature, respect the lessons of the past. I dapped established effective practices to your new reality instead of ruining the same lessons painfully.
Sometimes there's a tendency I think especially among younger people to throw out anything old especially in software and such a young field and itself and moving along. People don't say, oh, that was a chemistry. I don't remember it. That doesn't apply anymore. Yeah, it does. There's a lot of stuff that still applies that we've known for a long time and software and maybe you need to adapt it in some way.
But the ideas still apply. And so respect the body of knowledge that we have another piece of wisdom gets back to the. You can't change everything at once idea. But you can Something all the time. One way I suggest people do this as on every project you work on pick out two areas you want to get better at they could be specific technical practices or softer skills or anything else that you think would add value to your project work in your career.
Some of the things I chose various times in my career were things like build management or unit testing analysis and design modeling, writing requirements. Things that I said I need to learn more about that. So then spend a little bit of your time on your project warning about those areas and trying to actively apply them to get some experience with them on your current project and the third bit of wisdom that I think I like to pass along its before you decide to adopt any
particular solution. But you think is going to give you a great new results because you read an ad somewhere or that's what the person that the conference said, make sure you understand the real problem. I'm a big fan of root cause analysis. So let's say you're tempted to adopt some new methodology, I'll call it method 9, it's supposed to give you Like productivity or higher customer satisfaction or
some other fabulous goodness before you switch to Method. 9, first, ask yourself why are we not already having great productivity? Why do we not already have higher customer satisfaction than we do? So once you've done some root cause analysis then you can decide whether the solution you're considering is actually going to address the right problems. In other words, if method 9 is the answer, what was the
question? So, I think it's important to do some root cause thinking before you choose Is any new way to work, then you can make sure you're choosing the right one. Well, I really liked the last one. It's really wise to have that so because he has in software development, especially, we tend to follow this hype driven development, always chase the latest hype latest technology, be the next Google or whatever that is, and then try to apply that in our working environment. Okay.
Sometimes it's not the same problem, but because of that, it introduced more problems for the team and the company itself. So, thanks God for your time. For people who want to learn more about your work, maybe Other books, where can they find you online or where they can reach out if they want to continue this conversation with a personal website is Carl weekers.com, my company website is process impact.com and there's information at both of those about all of my books on
various topics. There's a lot of Articles I've posted a lot of particles both on the process impact.com site and on medium.com, I have 85 or so articles up there on a wide range of topics. So those are all places where people can learn a little bit more. Or another thing you can do it, call uyghurs.com that may not be obvious. My main hobby is recording music. Just for fun at home. I play guitar. I'm not a good singer. I'm not a great guitarist, but I don't let that stop me.
So, I like to record music and I have about 50. I think 51 Songs now had Carl uyghurs.com that I've recorded just me doing all the parts. Maybe a little help from some friends once in a while. 18 of them are songs that I wrote myself, in recorded in the restaurant, all covers of other songs. It's just a fun hobby. People who want to listen to new music. Instead of Spotify, go to Cal Wiggins.com and make sure to check out these original songs that Carl has produced.
So thanks a lot for your time. I'm really learning a lot from your pearls. I'm sure people would also learn something if they read from the books. So thanks again for your time. Thanks very much Henry's. Been a pleasure being with you today. Thank you for listening to this episode and for staying, right until the end, if you're highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode.
And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better. You can also find the full show notes of this conversation on the episode page at tackling journal, the death website, including the full transcript interesting. Courts and links to the resources mention from the conversation. And lastly, make sure to subscribe to the show's mailing list on package.
You know, that deaf to get notified for any future episodes. Stay tuned for the next technology, no episode. And until then goodbye.