Here are my notes from a very practical book The Coaching Habit by Michael Bungay Stanier:

The book covers 7 questions:

• Kickstart: What’s on your mind
• AWE: And what else?
• Focus: What’s the real challenge here for you?
• Foundation: What do you want?
• Lazy: How can I help?
• Strategic: If you’re saying yes to this, what are you saying no to?

• Learning: What was most useful for you?

• The essence of coaching lies in helping others and unlocking their potential

• If you need to have a lead in phrase, consider using: ‘out of curiosity’
• Three vicious circles that plague our workplaces: overdependence, getting overwhelmed, and becoming disconnected.
• Ask people more questions and give less advice
• 45% of our waking behavior is habitual
• If you spend too much time imagining the outcome, you’re less motivated to actually do the work to get there.
• Think less about what your habits can do for you, and more about how this new habit will help the person or people you care about.
• Charles Duhigg says that there are just five types of triggers: location, time, and emotional state, other people, and immediately preceding action.
• I will ask just one question and then be quiet while I wait for the answer.
• Coaching for performance is about addressing and fixing a specific problem or challenge. Coaching for development is about turning the focus from the issue to the person dealing with the issue, the person who’s managing the fire.
• 3P’s: people, projects, patterns
• The brain accounts for only 2% of the body weight, but it uses about 20% of the energy
• The first answer someone gives you is rarely the only answer, and it’s rarely the best answer.
• The brain counts like this: one, two, three, four…lots.
• Stop offering up advice with a question mark attached. That doesn’t count as asking the question. If you’ve got an idea, wait. Ask, “And, what else?”, and you’ll often find that the person comes up with the very same idea that’s burning a hole in your brain.
• The simple act of adding ‘for you today’ to the end of as many questions as possible is an everyday technique for making conversations more development than performance oriented.
• Stick to the question starting with “What” and avoid questions starting with “Why”.
  • Why did you do that? => What were you hoping for here?
  • Why did you think this was a good idea? => What made you choose this course of action?
  • Why are you bothering with this => What’s important for you here?
• The single biggest problem with communication is the illusion that it has taken place. ~ G.B. Shaw
• 9 universal needs based on Marshall Rosenberg: affection, creation, recreation, freedom, identity, understanding, participation, protection, subsistence
• Five times a second, at an unconscious level, your brain is scanning the environment around you and asking itself: it’s safe here, or is it dangerous?
• After asking a question, just patiently wait for an answer.
• Based on Karpman, there are three archetypal roles: victim, persecutor, and rescuer
• While talking nod your head, make encouragement noises and maintain
• Being busy is no measure of success
• The essence of strategy is choosing what not to do. ~ Michael Porter
• Acknowledge the reply of a person by saying, “Yes, that’s good”, instead of just going into another question.
• People don’t really learn when you tell them something. They don’t even really learn when they do something. They start learning, start creating new neural pathways, only when they have a chance to recall and reflect on what just happened.
• This is why, in a nutshell, the advice is overrated. I can tell you something, and it’s got the limited chance of making its way into your brain’s hippocampus, the region that encodes memory. If I can ask you a question and you generate the answer yourself, the odds increase substantially.x
• What have you learned since we last met?
• So, what was most useful here for you? What did you find most valuable about this chat? What worked best here?
• Finish on a high note, and you make everything that went before it look better.
• “Before I jump into a longer reply, let me ask you: What’s the real challenge here for you?

TL;DR

You can read all about how we implemented our 1st book club idea in our engineering team, and in this post, I’m going to do the same but with a new book. In this short post I’ll tell you:

• how we implemented the second book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few learnings, comments and (as I usually do in my book posts) quotes

What book did we read?

We read the book called It Doesn’t Have to Be Crazy at Work by Jason Fried and David Heinemeier Hansson.

It seems that the Goodreads and Amazon reviewers liked the book.

However, I’m not really sure why, because this is how much we liked (or better said didn’t) the book. So, 4.5/10 with a max rating of 6 says a lot.

How did we do it?

We read it in only three weeks which means it was a really easy read. This comes down to about 75 pages per week, which amounts to 15 pages per work day.

On average, it took us 2hr and 22 minutes to finish the book, or about 9 minutes per work day.

Here’s a short post on the math behind reading 30 books per year in case you’re interested.

What did we like?

Even though we didn’t like the book in general, it still had some parts that we liked:

• Office hours idea
• Stance towards interviews – and paying for spec work
• Company is not a family
• Salary negotiation is crap
• Calm goodbyes
• Fridays off during summer

What we didn’t like

A lot of the chapters were common sense, and we agreed with them (few mentioned above), but some of the things we just couldn’t agree with:

• No goal setting
• Not going out of your comfort zone – promoting mediocrity
• It seems like the whole book is an advertisement for them
• They support multiple versions
• This most probably won’t work for a bigger company

Some quotes

As usual in my book posts, here are some quotes that we liked:

• We don’t mind leaving some money on the table, and we don’t need to squeeze every drop out of the lemon. Those final drops usually taste sour, anyway.
• There is nothing so useless as doing efficiently that which should not be done at all.
• Your company is a product. If you want to make the product better, you have to keep tweaking, revising, and iterating.

• Comparison is the death of joy.

Conclusion

Even though we didn’t like the book in general, it definitely wasn’t a total waste of time. We already started with the next book (Pragmatic Programmer), and this time we hope the book to be better.

A question for those that already conducted book clubs in your engineering organizations – what books did you read?

Here are my favorite quotes from the book Way of the Warrior Kid: From Wimpy to Warrior the Navy SEAL Way: A Novel by Jocko Willink:

If you need rest, you go to sleep earlier. You don’t sleep in, and you don’t miss workouts. Even if you can’t perform at a high-level, showing up and doing something is still a thousand times better than not showing up at all.

The most important part of discipline is following rules that you set for yourself. It is doing things you might not always feel like doing – things that make you better.

I don’t worry about motivation, because motivation comes and goes. It’s just a feeling. You might feel motivated to do something, and you might not. The thing that keeps you on course and keeps you on the warrior path isn’t motivation. It is discipline. Discipline gets you out of bed. Discipline gets you onto the pull-up bar. Discipline gets you to grind it out in the jiu-jitsu class.

We don’t quit. Ever.

Fear is normal. In fact, fear is good. Fear is what warns you when things are dangerous. Fear is what makes you prepare. Fear keeps us out of a lot of trouble. So there is nothing wrong with fear. But fear can also be overwhelming. It can be unreasonable. It can cause you to freeze up and make bad decisions or hesitate when you need to act. So you have to learn to control fear. And that’s what you need to do right now.

The fear is in the waiting. Once you have prepared, trained, studied and planned, there is only one thing left to do: go.

You know the path. And you are humble. That is the most important thing about being a leader.

Here are my favorite quotes from the book Peak: Secrets from the New Science of Expertise by K. Anders Ericsson.

You have to keep upping the ante: run farther, run faster, run uphill. If you don’t keep pushing and pushing and pushing some more, the body will settle into homeostasis, albeit at a different level than before, and you will stop improving.

The best way to get past any barrier is to come at it from a different direction, which is one reason it is useful to work with a teacher or coach. Even the most motivated and intelligent student will advance more quickly under the tutelage of someone who knows the best order in which to learn things, who understands and can demonstrate the proper way to perform various skills, who can provide useful feedback, and who can devise practice activities designed to overcome particular weaknesses.

You seldom improve much without giving the task your full attention.

Deliberate practice involves well-defined, specific goals and often involves improving some aspect of the target performance; it is not aimed at some vague overall improvement. Once an overall goal has been set, a teacher or coach will develop a plan for making a series of small changes that will add up to the desired larger change. Improving some aspect of the target performance allows a performer to see that his or her performances have been improved by the training. Deliberate practice is deliberate, that is, it requires a person’s full attention and conscious actions. It isn’t enough to simply follow a teacher’s or coach’s directions. The student must concentrate on the specific goal for his or her practice activity so that adjustments can be made to control practice.

You don’t build mental representations by thinking about something; you build them by trying to do something, failing, revising, and trying again, over and over. When you’re done, not only have you developed an effective mental representation for the skill you were developing, but you have also absorbed a great deal of information connected with that skill.

TL;DR

In this post I’m going to show you:

• how we implemented the book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few learnings, comments and (as I usually do in my book posts) quotes

Those interested in some data metrics, scroll to the end of the post, after the quotes 🙂

What book did we read?

We read the book called The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford. This is a book that, arguably, everyone in IT should read.

The book is really awesome, and here’s the Amazon rating:

If you don’t trust Amazon for some reason, here’s the Goodreads rating:

The rating score of 4.25 out of 5 from almost 19k votes is a lot on Goodreads.

How did we do it?

We started reading the book on Jan 21st and finished it on Mar 11th. So, for 6 weeks we read approximately 50 pages per week and then discussed it in our mobile dev team meetings.

This is only 10 pages per workday, in case you were wondering. Here’s a short post on the math behind reading 30 books per year in case you’re interested.

What did we learn?

We learned that there are 4 types of work:

• business projects
• internal projects
• changes
• unplanned work

We learned some new phrases like FUBAR and MOADF, and we learned that everyone needs idle time, because if no one has idle/slack time, WIP (work in process) gets stuck in the system just waiting.

Also, we learned that getting the whole company working together to the same common goals only works if people know what the goals are. So, it’s good to have OKRs/KPIs/yourVersionOfGoalTracking publicly available and set by each department and their team members.

What discussions did the book start

The book also spurred some exciting discussions about:

• how could we get to the single-piece flow
• how to deal with unplanned work
• what to do when asked to deploy something on Friday
• what are our bottlenecks
• how does our WIP look like
• what ticket management systems we used in the past, etc.

What we didn’t quite like

There were some things that we didn’t like:

• the ending was too happy-go-lucky; we expected something more along the lines of a Game of Thrones ending
• Bill’s wife
• Brent was too realistic, gave few of us scary flashbacks
• Bill didn’t treat developers with respect. I quote:
  • “Developers – I had forgotten how quirky they can be. To me, they seem more like indie musicians than engineers.”

Characters

Speaking of characters, it seems like we all liked the Eric character, which could be described as a mix of Doc and Jack Sparrow. That also knows a lot about process and IT and also surfs not only the internet.

Since every good novel has to have a villain, this one did as well. We liked the fact that Sarah got what was coming for her in the end. And we even toyed with an idea of who would play this character in the “The Phoenix Project” movie. Here are a few options that were mentioned:

Some quotes

As usual in my book posts, here are some quotes that we liked:

• “Until code is in production, no value is actually being generated, because it’s merely WIP stuck in the system.”
• “He has a well-deserved reputation as one of the most fun people in the company to travel with. The size of his expense reports proves it.”
• “Practice creates habits, and habits create mastery of any process or skill.”
• “A good day feels like my staff panicking about the size of the commission checks we’re going to be writing them”
• “I’ve realized that having people give you honest feedback is a rare gift.”
• “You need to get everything in version control. Everything. Not just the code, but everything required to build the environment. Then you need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on-demand. That’s how you reduce your setup times and eliminate errors, so you can finally match whatever rate of change Development sets the tempo at.”
• “Developers – I had forgotten how quirky they can be. To me, they seem more like indie musicians than engineers.”
• “Any COO who doesn’t intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job.”
• “Effectively managed IT is a significant predictor of company performance.”
• “IDC, the analyst firm, says that there are 11M devs and 7M operations people on the planet.”
• “To tell the truth is an act of love. To withhold the truth is an act of hate. Or worse, apathy.”
• “In these competitive times, the name of the game is quick time to market and to fail fast.”
• “Turning around, he says, “In any system of work, the theoretical ideal is single-piece flow, which maximizes throughput and minimizes variance. You get there by continually reducing batch sizes. “You’re doing the exact opposite by lengthening the Phoenix release intervals and increasing the number of features in each release. You’ve even lost the ability to control variance from one release to the next.”

Show me the data!

So, it does seem that we liked it and had fun, but how do you measure that?

This is how much we liked the book on a scale from 1-10:

Funny piece of trivia was that iOS devs used floats, and Android devs used integers. ?

This is how much we liked the book club implementation on a scale from 1-10:

And, finally, this is how likely we want to do this again in Q2 on a scale from 1-10:

I promise I didn’t set this graph up on purpose to look like this, but it does look kinda cool. ?

Conclusion

We liked this experiment and will continue doing it. I hope you found it valuable and that you also may wanna try out this within your teams. If you have any questions, please ask in the comments section.

And, a question for those that already conducted book clubs in your engineering organizations, what books did you read?

How we implemented the #book #club idea in our #engineering team https://t.co/lLQ5LuVUw6

— Nikola Brežnjak (@HitmanHR) March 25, 2019

Here are my favorite quotes from the book The Productivity Project by Chris Bailey.

Make a list of all the things you’re responsible at your work. Then, ask yourself which is the most important item on that list and go do it.

At the end of every day decide which three tasks you want to accomplish by the end of the next day.

Manage your energy, not time.

Write and send a letter to yourself in the future.

Limit your time for a certain task to half of what you thought it’s going to take and see how it goes.

Don’t sort emails in folders – search for them.

Alcohol has a significant impact on your energy levels and productivity.

The brain can’t tell much difference between visualization and actual experience. Therefore, at the end of the day recall the positive and meaningful parts of your day – that way you double the significant experiences of your day.

77% of what we think is negative, counterproductive, and works against us. Therefore, force yourself to feed your brain with positive thoughts.

I’ve learned most from the meditation experiment where I lived in isolation for 10 days and meditated for 35+ hours.

Busyness is no different from laziness when it doesn’t lead you to accomplish anything.

You’re 7 times as likely to be highly engaged at work if If your best friend works at the same place.

The best attitude to have with productivity is never to be satisfied but to find ways to cultivate happiness continually.

Please stop multitasking 🙂

Here are my favorite quotes from the book The Coaching Mindset: 8 Ways to Think Like a Coach by Chad W. Hall.

Rather than tell people what to do, I helped people tell themselves what to do.

Don’t try to solve the problem for them, help them to get to the solution themselves.

When you think the highest value you bring to your coaching client is your intellect, your brilliance, your awesome problem-solving abilities, your creativity, or your whatever, you get in the way. That’s because coaching is about bringing out the intellect, brilliance, awesome problem-solving ability and creativity of your client. Coaching is a chance for the client to shine, not for you to shine.

The coach’s brain works not to solve, but to facilitate the client’s solving. The coach’s brain is not trying to think two, three, or four steps ahead, but to be with the client in the present moment as she thinks.

I am suggesting that you treat the coaching conversation like an adventure movie in which the client is the star, the hero, the main character, and the one moving the action forward.

The bigger the client’s challenge, the more important it is to let the client be the hero.

After all that thinking you might finally ask, “What can you do to make this a priority?” The problem here is that your question is the result of too much processing. A far better question would be the first question you asked yourself: “What do you mean by stuck?”

Great coaches train themselves to notice their own thinking and to stop or back up the thinking process so they say simple, primitive stuff that invites the client to process.

Primitive questions are powerful invitations for the client to explore something. Like: What do you make of that? How should we get started? Where are we in this conversation? What about that is really important to you? What’s a good way to unpack this? What’s your decision-making process need to be?

Whatever your client says, just go with it. Go with positivity, curiosity and a spirit of “Yes.”

The enemy of curiosity is judgment. On the other hand, curiosity opens up the learning process.

Pretending to know or assuming you know is a bad thing.

This sounds like a really important issue for you. What’s the best way for us to get started with it?

Don’t re-live the things your clients share as if it happened to you.

Your ability to remain somewhat objective is one of the greatest gifts you can give your client because it becomes the bridge to greater insight. Your objectivity merely enables you to invite the client to get on the balcony where he can see himself and his situation more clearly.

Here are my favorite quotes from the book Can’t hurt me by David Goggins.

I’ve reviewed this one on Goodreads like this:

Wow, just wow.

The book is phenomenal, and the Audible format with comments is an awesome idea.

Everybody needs to read this book and get a kick in their ass by this remarkable man’s story.

Hat down Mr. Goggings, hat down.

Maybe your limiting factor is that you grew up so supported and comfortable that you never pushed yourself?

The first step on a journey towards a callous mind is stepping outside of your comfort zone on a regular basis.

The reason it’s important to push hardest when you want to quit the most is because it helps you callous your mind. It’s the same reason why you have to do your best work when you are the least motivated. That’s why I loved PT in BUD/S and why I still love it today. Physical challenges strengthen my mind, so I’m ready for whatever life throws at me, and it will do the same for you.

You have to put work behind everything in life for it to change for the better.

You wanna get to the point in your life where everything that you should have done and you didn’t do – it bothers you.

There is no shame in being knocked down. The shame comes when you throw in the mother fucking towel.

Only when you identify and accept your weaknesses, when you finally stop running from your past – then those incidents can be used more efficiently as fuel to become better and grow stronger.

Those that know don’t speak. And those who speak, well, they don’t know jack shit.

The average person thinks 2000-3000 thoughts per hour. Rather than focusing on bullshit, you can not change, imagine visualizing the things you can.

If you don’t account for the ‘might happen’, when it does happen you won’t know what to do.

Start to, really, use your mind – it’s the most powerful weapon in the world.

If everyone starts pushing a little harder, doing a little bit more for themselves and others – what would happen?

By now I’m sure you can tell that it doesn’t take much for me to be obsessed. Some criticize my level of passion, but I’m not down with prevailing mentalities that tend to dominate our society these days. The ones that tell us to go with the flow or invite us to learn how to get more with less effort. Fuck that shortcut bullshit! The reason I embrace my own obsessions and demand to desire more of myself is because I’ve learned that only when I push beyond pain and suffering, passed my perceived limitations that I’m capable of accomplishing more physically and mentally in endurance races but also in life as a whole.

Always be willing to embrace ignorance and become the dumb fuck in the classroom again. Because that’s the only way to expand the body of knowledge and body of work. It’s the only way to expand your mind.

Greatness is not something that if you meet it once it stays with you forever.

It’s not the external voice that will break you down. It’s what you tell yourself that matters. The most important conversations that you’ll ever have are the ones you’ll have with yourself.

We need to shoot for more than what we even thought was possible. We have to go into a point in our lives where there is no finish line, there is no end, and to find true pride in what you’ve done on this Earth.

Can't hurt me – David Goggins, wow! just wow! https://t.co/tSAo79IXDG

— Nikola Brežnjak (@HitmanHR) March 11, 2019

My favorite quotes from a remarkable book called How Will You Measure Your Life? by Clayton M. Christensen, James Allworth, and Karen Dillon.

How can I be sure that:

• I will be successful and happy in my career?
• My relationships with my spouse, my children, and my extended family and close friends become an enduring source of happiness?
• I live a life of integrity – and stay out of jail?

He’s forgotten more than I will ever know about his business.

People often think that the best way to predict the future is by collecting as much data as possible before making a decision. But this is like driving a car looking only at the rearview mirror – because data is only available about the past.

The only way a strategy can get implemented is if we dedicate resources to it. Good intentions are not enough – you’re not implementing the strategy that you intend if you don’t spend your time, your money, and your talent in a way that is consistent with your intentions.

True motivation is getting people to do something because they want to do it.

Hygiene factors are things like status, compensation, job security, work conditions, company policies, and supervisory practices. Motivation factors include challenging work, recognition, responsibility, and personal growth.

⚠️ If you want to help other people, be a manager. If done well, management is among the most noble of professions.

Find a job that you love, and you’ll never work a day in your life.

When you find out what really works for you, then it’s time to flip from an emergent strategy to a deliberate one.

It’s really not until twenty years down the road that you can put your hands on your hips and say, “We raised good kids”.

But there is much more to life than your career. The person you are at work and the amount of time you spend there will impact the person you are outside of work with your family and close friends. In my experience, high-achievers focus a great deal on becoming the person they want to be at work – and far too little on the person they want to be at home. Investing our time and energy in raising wonderful children or deepening our love with our spouse often doesn’t return clear evidence of success for many years.

The relationships you have with family and close friends are going to be the most important sources of happiness in your life.

Capital that seeks growth before profit is bad capital.

The path to happiness is about finding someone who you want to make happy, someone whose happiness is worth devoting yourself to.

If a company has strong processes in place, managers have flexibility about which employees they put on which assignments – because the process will work regardless of who performs it.

Self-esteem comes from achieving something important when it’s hard to do.

If your children gain their priorities and values from other people – whose children are they?

Helping your children learn how to do difficult things is one of the most important roles of a parent.

Encourage them to stretch – to aim for lofty goals. If they don’t succeed, make sure you’re there to help them learn the right lesson: that when you aim to achieve great things, it is inevitable that sometimes you’re not going to make it. Urge them to pick themselves up, dust themselves off, and try again. Tell them that if they’re not occasionally failing, then they’re not aiming high enough. Everyone knows how to celebrate success, but you should also celebrate failure if it’s a result of a child striving for an out-of-reach goal.

Allow the child to see the consequences of neglecting an important assignment.

Culture in any organization is formed through repetition.

It’s easier to hold to your principles 100 percent of the time than it is to hold to them 98 percent of the time.

The only metric that will truly matter to my life are the individuals whom I have been able to help, one by one, to become better people.

⚠️ Treat people as if they were what they ought to be and you help them become what they are capable of being.

My notes from a remarkable #book How Will You Measure Your Life by Clayton M. Christensen https://t.co/wh8doLxSI2

— Nikola Brežnjak (@HitmanHR) February 19, 2019

I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

Other blog posts in this series:

• Part 1 (Chapters 1 – 4): Laying the Foundation
• Chapter 5: Design in Construction
• Chapter 6: Working Classes
• Chapter 7: High-Quality Routines
• Chapter 8: Defensive programming
• Chapter 9: Pseudocode Programming Process
• Chapter 10: General Issues in Using Variables
• Chapter 11: General Issues in Using Variables
• Chapter 12: Fundemental Data Types
• Chapter 13: Unusual Data Types
• Chapter 15: Using Conditionals
• Chapter 16: Controlling Loops
• Chapter 17: Unusual Control Structures
• Chapter 18: Table-Driven Methods
• Chapter 19: General Control Issues

⚠️ Users care about whether the software is easy to use, not about whether it’s easy for you to modify. They care about whether the software works correctly, not about whether the code is readable or well structured.

⚠️ The General Principle of Software Quality is that improving quality reduces development costs. Understanding this principle depends on understanding a key observation: the best way to improve productivity and quality is to reduce the time spent reworking code.

Characteristics of Software Quality

The software has both external and internal quality characteristics. External characteristics are characteristics that a user of the software product is aware of, including the following:

• Correctness
  • The degree to which a system is free from faults in its specification, design, and implementation
• Usability
  • The ease with which users can learn and use a system
• Efficiency
  • Minimal use of system resources, including memory and execution time
• Reliability
  • The ability of a system to perform its required functions under stated conditions whenever required – having a long mean time between failures
• Integrity
  • The degree to which a system prevents unauthorized or improper access to its programs and its data. The idea of integrity includes restricting unauthorized user accesses as well as ensuring that data is accessed properly
• Adaptability
  • The extent to which a system can be used, without modification, in applications or environments other than those for which it was specifically designed
• Accuracy
  • The degree to which a system, as built, is free from error, especially with respect to quantitative outputs. Accuracy differs from correctness; it is a determination of how well a system does the job it’s built for rather than whether it was built correctly
• Robustness
  • The degree to which a system continues to function in the presence of invalid inputs or stressful environmental conditions

Programmers care about the internal characteristics of the software as well as the external ones. So here is a list of internal quality characteristics:

• Maintainability
  • The ease with which you can modify a software system to change or add capabilities, improve performance, or correct defects
• Flexibility
  • The extent to which you can modify a system for uses or environments other than those for which it was specifically designed
• Portability
  • The ease with which you can modify a system to operate in an environment different from that for which it was specifically designed
• Reusability
  • The extent to which and the ease with which you can use parts of a system in other systems
• Readability
  • The ease with which you can read and understand the source code of a system, especially at the detailed-statement level
• Testability
  • The degree to which you can unit-test and system-test a system; the degree to which you can verify that the system meets its requirements
• Understandability
  • The ease with which you can comprehend a system at both the system-organizational and detailed-statement levels. Understandability has to do with the coherence of the system at a more general level than readability does

The attempt to maximize certain characteristics inevitably conflicts with the attempt to maximize others. Finding an optimal solution from a set of competing objectives is one activity that makes software development a true engineering discipline. But then again, that doesn’t mean that there has to be a tradeoff with another characteristic. Sometimes one hurts another, sometimes one helps another, and sometimes one neither hurts nor helps another. For example, focusing on adaptability helps robustness and vice versa.

Techniques for Improving Software Quality

Although it might seem that the best way to develop a high-quality product would be to focus on the product itself, in software quality assurance you also need to focus on the software development process. Here are a few tips for improving software-quality:

• Setting explicit quality goals
• Making the quality assurance activity explicit makes the priority clear, and the programmers will respond by focusing more on quality rather than how quickly they “complete” their programs
• Developing a testing strategy
• Informal technical reviews
• Formal technical reviews

Relative Effectiveness of Quality Techniques

The various quality-assurance practices don’t all have the same effectiveness. Here are some quality-assurance practices:

• Informal design reviews
• Formal design inspections
• Informal code reviews
• Formal code inspections
• Modeling or prototyping
• Unit tests
• Personal des-checking of code

Percentage of Defects Detected

Used on their own, the techniques detect on the average only about 40% of the errors. The strong implication is that if project developers are striving for a higher defect-detection rate, they need to use a combination of techniques. A study by Glenford Myers shows that using any combination of techniques increased the total number of defects found by a factor of almost 2.

Cost of Finding and Fixing Defects

Most studies have found that inspections are cheaper than testing. A study at the Software Engineering Laboratory found that code reading detected about 80% more faults per hour than testing. Another organization found that it cost six times as much to detect design defects by using testing as by using inspections.

As it was mentioned in previous chapters about design, the longer a defect remains in the system, the more expensive it becomes to remove. So a technique that catches the error earlier reduces the cost of fixing it. Even more important is whether the technique detects the symptoms and causes of defects in one step, e.g. inspections, or like testing, finds symptoms but require additional work to diagnose and fix the root cause.

The bottom line is that for a quality program you must use a combination of techniques, here’s my recommendation:

• Formal inspections of all requirements, all architecture, and designs for critical parts of the system
• Modeling or prototyping
• Code reading or inspections
• Execution testing

The general Principle of Software Quality

The General Principle of Software Quality is that improving quality reduces development costs. Understanding this principle depends on understanding a key observation: the best way to improve productivity and quality is to reduce the time spent reworking code.

The industry average productivity for a software product is about 10 to 50 of lines of delivered code per person per day (including all noncoding overhead). Part of the reason for these seemingly low productivity figures is that industry average numbers like these factor nonprogrammer time into the lines-of-code-per-day figure. But the single biggest activity on most projects is debugging and correcting code that doesn’t work properly.

The study at IBM produced similar findings:

Software projects with the lowest levels of defects had the shortest development schedules and the highest development productivity. Software defect removal is actually the most expensive and time-consuming form of work for software.

Keynote that you should take from this chapter is that quality is free, in the end, but it requires a reallocation of resources so that defects are prevented cheaply instead of fixed expensively ?