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.