Practical Software Engineering

Well, Peter Drucker didn’t write about software management, but he did write about management. In his book Managing in a Time of Great Change he has a chapter called The Five Deadly Business Sins. Here is what Drucker has to say:

The third deadly sin is cost-driven pricing. The only thing that works is price-driven costing. Most American and practically all European companies arrive at their prices by adding up costs and then putting a profit margin on the top.

The only sound way to price is to start out with what the market is willing to pay—and thus, it must be assumed, what the competition will charge—and design to that price specification.

How does this apply to software development? Here is how I see the two scenarios in the world of software development:

Cost-Driven Pricing: A Tough Sell

In this scenario the Customer comes with the software product requirements (not quite complete, since they never are). Next the software team goes ahead and figures out how long it is going to take to build it, and tells the Customer what the expected end-date is, thus arriving at a “cost.” The Customer is almost always unhappy with the end-date that the team provides. The Customer is also unhappy with the delivered product, since the software team usually does not manage the scope at a fine-grained level. The team thinks that they know what they need to build, and proceed on building it.

Price-Driven Costing: Problem Solving with Constraints

In this scenario the Customer comes with the requirements (never complete), and a target end date in mind: an end-date that fits into the business scenario that they intend to play out. It is now up to the software team to:

1. Figure out how the product can be built under the given constraints of date and cost, and
2. Figure out how to “slice & dice” the requirements to meet the Customer’s goals.

The software team must deliver to and negotiate with the Customer regularly. To deiver the project the team have to bring their ingenuity to solve the problem.

The Bottom Line

Price-Driven Costing applies to the way software teams work. It means that we need to work back from the price (date) that the Customer is willing to take, and then we have to figure out how to deliver the project on that date. There may be times when we have to say, this cannot be done. And there will be others, many others, when we will successfully deliver the project to a happy Customer.

When agility comes up in conversations, the typical topics are methods, techniques, or process, but rarely initiative. Even though initiative, more than other factors, determines if a team can perform at maximum performance. These days an organization cannot be competitive if its people are at levels 1 or 2 on the initiative scale.

Levels of Initiative [1]

1. Wait until told. The lowest level of initiative.
2. Ask what to do.
3. Recommend, and then take resulting action.
4. Act, but advise at once.
5. Act on own, then routinely report. The highest level of initiative.

Managers often unwittingly kill people’s initiatives, because managers make too many decisions that would better be done by others. If you notice that your manager is making a decision that could be handled more effectively by you, then recommend it. You might be surprised that he or she will gladly accept your assistance.
Do you think that your team could cut cycle time and improve quality if the team members acted at higher levels of initiative?

Reference

1. Oncken, Jr., William and Donald L. Wass, “Management Time: Who’s Got the Monkey?” Harvard Business Review (November-December 1974).

The July 3, 2006 issue of Business Week has a story on how innovation happens at Samsung. Samsung created a Value Innovation Program and have identified key brainstorming practices. The following quotes should give you an idea how they go about solving problems. One key tenet: each project works against a fixed deadline. Another one: they bring together everyone at the beginning to thrash out differences.

Find that perfect balance of cost, innovation, and technology that makes a product great.

Every step of the way, team members drew what Samsung calls “value curves.” These are graphs that rank various attributes such as picture quality and design on a scale of 1 to 5, from outright bad to excellent.

The story also suggests that it is not enough to look at a competitor’s product and replicate it. In today’s competitive world a company has to redo its culture to stay in a leadership position and be able to release one great product after another.

Summary

1. The purpose of the design and code reviews is to find defects.
2. The factor that most influences the length of a design or code review is the amount of work product that has to be reviewed. This may be pages of design or lines of code of source.
3. Checklist-directed reviews are the most effective at finding defects specific to the project and product. The checklist has to be built from past defects that the person or team had problems with most recently.

Starting a Review Practice in a Team

Checklist-directed reviews have a 70% to 90% yield in finding defects. The yield is defined as the percentage of defects found by the review that existed in the work product on entry into the review. When a team starts a review practice, there is no checklist yet. How can a Team get started? Here are some tips to get the reviews going.

What parts of the system to target for a review?

1. Create on a large piece of paper, or on a whiteboard, a map of the system that the team is working on.
   1. This map must include at least all the physical modules of the system, but going to a finer level of detail is better.
   2. Each system part drawn should represent around 2 KLOC of NCSS (KLOC=thousand lines of code, NCSS=Non Comment Source Statement).
2. Review the defect log.
   1. From the defect log select the most recent list of 100 defects (or whatever you have in the last month).
3. Place a mark by each system part for each defect that can be traced to that part.

The system part with the most marks gets to be the target of the investigation.

If after a cursory assessment it seems that finding and fixing all the defects in the part would take longer then rewriting it, then the team should choose the rewrite route.

How much code can you review?

The speed of the review seems to be constant on all projects. Ranges from about 200 to 300 NCSS per hour. Reviewing at higher speeds will make the reviewers miss what they are looking for.

What is the difference between a review and defect finding?

During the review the reviewer is looking at the source code, and when he/she notices a defect he is looking at it right then and there. There is no more detection needed. On the other hand, when the developer has to investigate a defect that is reported by a Customer, then first the reason for the defect must be established. This is a time consuming activity because it contains a great deal of uncertainty.

What to look for in a review?

It is best to look for defects that had been observed already. Chances are that the defects that were noted in some part of the system, are present in some other part of the system as well (especially if they both have just been worked on).

Types of Reviews

1. Personal Review
2. Peer Review
3. Inspection
4. Walkthrough

Review Principles

Personal reviews follow a process with

• entry and exit criteria
• a defined review structure
• guidelines, checklists, and standards

The personal review goal is to find every defect before the first unit test. To address this goal:

• use coding standards
• use design completeness criteria
• measure and improve your review process

Design Review Principles

1. Produce designs that can be reviewed.
2. Follow an explicit review strategy.
3. Review the design in stages.
4. Verify that the logic correctly implements the requirements.

What is a Reviewable Design?

A reviewable design has:

1. defined context
2. precise representation
3. consistent and clear structure

This suggests that:

1. the design’s purpose and function is explicitly stated
2. you have criteria for design completeness
3. the design is explicitly structured in logical elements

Checklists

Checklists: The Theory

1. When performing precise tasks, it is difficult to do more than one thing well at a time.
2. The checklist defines the review steps in the suggested order for performing them.
3. By checking off each item, you are more likely to perform it properly.
4. Establish a personal checklist that is customized to your defect experience.
5. Process yield is the percentage of defects found before the first unit test execution. (70%+)

Checklists: HOWTO

1. Use your review strategy.
2. Review one product component at a time.
3. Check for one type of defect at a time.

Checklists: The Key Point!

Treat each check as a personal certification that the product is free of this defect.

For Extra Credit: Estimating Remaining Defects After a Peer Review

Use the Capture-Recapture Method:

• A: The number of defects found by the first reviewer.
• B: The number of defects found by the second reviewer.
• C: The number of defect found by both the first and the second reviewer.

Estimated total number of defects in the product: E = A * B / C
Total defects found so far: D = A + B – C
Estimated remaining defects in the product: R = E – D = (A * B / C) – (A + B – C)
Inspection Yield: Y = D / E * 100

HOWTO Quick Summary

1. Pick a piece of code that you are uneasy about.
2. Review it for defects that you had recently. KEEP A LIST!
3. Keep your review speed at 200 LOC/hr. Plan ahead!
4. Only look for one defect at a time.
5. Treat each check as a personal certification that the product is free of this defect.

See Also

Guiding Principles for Reviews from Wiegers

1. Check your egos at the door (Weinberg)
2. Keep the review team small.
3. Find problems during reviews, but don’t try to solve them.
4. Limit review meetings to about two hours.
5. Review only about 200 to 400 NCSS per hour.
6. Start the reviews where the perceived pain is the greatest.
7. “It is only a mistake if it gets out of the review.”
8. “Avoid using technical reviewers who are themselves ‘above’ review.”

References

1. Peer Reviews in Software, by Karl Wiegers
2. Introduction to the Team Software Process, by Watts Humphrey
3. When two eyes aren’t enough, by Karl Wiegers
4. Seven Thruths About Peer Reviews, by Karl Wiegers
5. Seven Deadly Sins of Software Reviews, by Karl Wiegers
6. Handbook of Walkthroughs, Inspections and Technical Reviews, by Freedman and Weinberg

Business and society operates on commitments. For your commitments to be more than just empty statements, you must base those commitments on a plan of action. Creating plans is activity that can be learned. It takes practice to become good at planning.

Sage advice: because the business can only operate on commitments, commitments will be made. If you don’t create a plan of action, then the commitments will be made without your input, but you will still be held responsible for making them. It is in your best interest to be actively involved in planning and tracking your work so you can make real commitments that you can keep.
Guidelines

Start with the end in mind!

Start with the end in mind is a statement made popular by Stephen R. Covey’s book, “The 7 Habits of Highly Effective People.” This applies to software development very well. Think through your objectives for the project, and figure out what are the deliverables that you have to produce to be done.

Identify your work products: The Deliverables

Think through and answers the following questions:

1. What is the end result of your work?
2. What is your “value add” on the project?
3. What is your contribution to the project’s success?
4. In what order do you have to create your work products?

The answers to the above questions will clarify to you what you have to do on the project.

Identify the milestones

It is a mistaken assumption that because you don’t produce “running code” as a result of what you do, therefore your deliverable is not that important, and therefore it doesn’t have to be planned and delivered according to a committed schedule. This thinking is dangerous. Your deliverable, the work product that you produce is an input to some other person’s process, and if you are unable to create your deliverable, then the person counting on your output will not be able to produce their deliverable. Your work product might be a: presentation, white paper, design diagram, UI sketch, etc. Whatever it is, as long it is an input to somebody else’s process (or to your own process a few days down the road), you need to ensure that it is delivered on the agreed upon schedule and with the agreed upon quality.

Unless you are working on a simple and quick deliverable, say one deliverable that takes 8 to 10 hours to create, do not try to make the deliverable in one shot: “Divide and conquer.” Take your work product, and figure out what are the intermediate stages in which it has to go through to be created. Identify what could be its constituent parts, and in what order should you create those constituent parts. Then figure out the tasks you have to do to make those parts and then to assemble your work product.

Identify the work

A task list is nothing more than the work that you know that you have to do to get a set of deliverables done.

What will you do first? What will you do next?

Let’s suppose that it is Monday morning, the first day of the new project. You arrive to the office early to get ready for the new project. What will you do first? Write these few things that come to your mind down on your task list. Write down your first few tasks as you would do them on the first day of the project. You would have to think about what will you do anyway, wouldn’t you? So, write them down. Then think about the next milestone. How are you going to achieve that? What will you have to do? You will do … … And then what? Write that down, too. Your goal should be to write down everything that you have to do to make the project work.

Write tasks based on what you will know when you get to start the task not what you know now

At some point as you write down your tasks you encounter the familiar feeling: “Yeah, but… I do not know what will I do after getting to xyz.” What are you supposed to know at the time when you get to that point? You sure will have learned some new stuff. If you wouldn’t be planning on learning anything, then you would have to use your existing knowledge and that means that you should be able to use all the knowledge that you have now.

What do you expect to learn as you work through the tasks of the project? Based on what you expect to learn, now, as you are writing the tasks, you can assume that when you will get to that point in your project, you will have learned what you planned to learn, or you have replanned the project, because you realized that you are not able to learn what you need to.

Of course, the assumptions that you make should go on your Personal Assumptions List. This may also be a new thing for you, so keep the assumptions list in writing. Remember: the problem with assumptions is not that we make them–after all we make them all the time–but rather the problem is that we make them and we never realize when an assumption “changes sign,” or goes from true to false. Every time when you notice that an assumption is going south, then you need to update your plan, since part of your plan is no longer true.

When you think of a new task, write it down!

This may sound obvious, but it is not. It is much better to have captured more tasks and then throw some out, than far fewer then you need. The insight about how to do something might come to you when you least expect it. Write it down! Don’t count on the “great” insight to come again and again.
Update your task list early and often!

The task list must represent at all times your best understanding of what needs to be done to complete the project. While it is important that you keep a history of the task as you started out with, it is even more important to always know what comes next and what is left to do to get the work done.

If you catch yourself that you are working on something that is not on your task list, then add the task to your list. The task list serves two purposes: it show what you expect to do, and–through the time log–it shows what you actually did.

Log time against a task that you planned to do

Logging time is considered by many folks–especially software folks–one of the most difficult things to do. Logging time is easier if–whenever you ask yourself the question “What do I have to do?”–you turn to your task list and start working on your next open task.

Twice a day, at mid-day, and at the end of the day, check your time log and ask the following questions from yourself:

1. Did I do what I planned to do?
2. How much time did I log?
3. Is there a good reason for having logged only this much time? What is the reason?

Understand the reason for the variation

By itself the data that you get about your planning and tracking process is very good. But it is even better to look at the variation of your data from day-to-day and from week-to-week. Seek to understand the reason for the variation. If there is no variation, but you are not happy with the results, then look into how you could make some changes that would cause a positive improvement in your data.

To sum it all up: At first planning is hard. With practice you can get pretty good at it. Your corporate life will be better when you will become known as a person who can make and meet commitments.

It seems that all professionals have their tools, but somehow managers were forgotten. No more! There is a great podcast to provide the tools that managers need to do their jobs better called Manager Tools. The podcast is done by Mark Horstman and Mike Auzenne. They publish their podcast weekly and have a website with materials that every manager needs. Check them out and listen weekly!

One of the many interesting stories from They Made America: Two Centuries of Innovators from the Steam Engine to the Search Engine, by Sir Harold Evans is the story of Samuel Insull. His innovation was in pricing. He worked on understanding how his customers would use electricity, and then devised a pricing method to meet the estimated need. A key part of his understanding was that he saw the peeks and valleys in the usage chart between the very different customer populations. His insight came to him because he looked at the entire system of generating and using electricity.

If you don’t yet know who Phil McKinney is, then you need to look him up. More importantly, you need to listen to his podcast, Killer Innovations. Phil’s insight into the innovation process provides you with knowledge you can use in your daily work.

You know the feeling: you are assigned to a new project and asked to give an “estimate” of the length of time the new project will take. You think about it for a moment—or for a day—and then give the date. But you have no confidence in the date, so before you give it you double it, or triple it, hoping that the new date will give you just enough time to take care of most of the unexpected things that might come up.

Both you and I know that this is not adequate, since this almost never yields the correct date. I never trusted the date since I never understood why the fudge factors were needed. But the biggest problem I had with estimation was that I didn’t know how to get better at it, since I didn’t understand how it worked.

It was in early 1992 that I first paid attention to something called the software process. I read Watts Humphrey’s Managing the Software Process. Humphrey points out some of the common process issues that every software organization has to face and how to get a handle on them. I started applying his ideas in a small group, not quite what he designed them for. Shortly after Humphrey finished writing his book he realized that the Capability Maturity Model that he described must be applicable for a person as well. He proceeded to write a book for the individual engineer: A Discipline for Software Engineering—The Personal Software Process. That book put the role of the individual engineer in a new perspective. Later, I had a chance to attend Humphrey’s seminars for engineers, managers and executives and I started teaching it, and mentoring people on its use as well.

Today I know that you get a better overall estimate if you estimate the size of the software first. Then you apply to the size estimate your productivity rate to get the project effort estimate (in hours). If you don’t know what your productivity is, then you will have to estimate it, and reestimate the project effort as soon as you have real data. If you work with short iterations then in a few weeks you should have real data, so your effort estimate will become more accurate.

Once you had figured out how many hours will the project take you can move on to figure out the date when it will be done. First, you consult your calendar and see how many hours you will have available for project work. Second, map the project hours onto the available calendar hours. This will give you a date that is pretty realistic. You might not like it, but this is a realistic date.

A major benefit to coming up with the date like this is that it gives you three levers that you can use to control the the end date:

1. You can reduce the scope of the project,
2. Be more productive (likely you can change this lever only in the long term), or
3. Work more hours (only a short term solution, because if you sprint when you are running a marathon, sooner or later you will run out of steam and you will never finish).

Since these three are independent variables, they require different actions. In the short term, you can reduce the scope of the project if you can’t add more hours either by working more or adding other people to the project. As we know from Fred Brooks, adding more people to an already late project will only make it later.

In 1999 I read The Fifth Discipline, The Art and Science of The Learning Organization by Peter Senge. This work, together with two follow-up works, The Fifth Discipline Fieldbook and The Dance of Change, pointed out to me the importance of looking at systems, not just software engineers, development teams, customers, companies, and suppliers. Senge’s work on systems seems comparable to Peter Deming’s work on quality. Senge’s work is not yet appreciated by most organizations.

To close the improvement circle I came back to the individual engineer. It is the individual engineer’s work that determines how good the product will be. The PSP (Personal Software Process) augmented with the TSP (Team Software Process)—both by Watts Humphrey—promise that by helping the engineering team get better—one engineer at a time—the end product will get better as well. Humphrey and his fellows from the SEI has thought the PSP class to thousands of engineers and gathered enough data to back up his claims. The doubters are welcome to try it for themselves.

There are many new challenges in the field of software engineering and I don’t anticipate running out of things to learn and practice. The main focus for the near future is:

• Integrating size measurement into object-oriented analysis and design;
• Studying and practicing Six Sigma and figuring out ways to apply DMAIC (Define, Measure, Analyze, Improve, and Control) in the context of the Software Life Cycle;
• Studying and practicing Systems Thinking and the other four management disciplines: Personal Mastery, Mental Models, Shared Vision, and Team Learning to create an organization that lives up to its full potential.

It must be an inner drive that I like to see things done, and that I have taken up interest in getting things done from an early age. As far as I remember, I have always headed a little group and worked on some sort of project that I wanted to see completed, preferebly sooner, then later. I have a natural inclination toward leadership. Several groups have appointed me to become their leader, and I took up leadership positions on my own.

The first time I formally started paying attention to management was in early 1991 when I watched Tom Peters in a PBS Special about MCI and other companies that he visited to learn about their work practices. I became a fan of Tom’s and have been following his work ever since, as well as read up on his earlier work (pre 1991).

Since I didn’t get a formal education in management—and in 1991 had no intent on becoming a manager—I decided to learn about management on my own primarily out of curiosity. I started reading books that would help me understand what should a manager do and, later, how can one go about becoming an excellent manager. I tracked down and read books that I considered would help. You can find most of the books I read on my reading list.

When one is a manager, then almost invariably the question of “management philosophy” tends to come up. My philosophy, if I should call it such, is to hire the right people and then get out of their way, support them, enable to get their work done. I ask lots of questions, to help my team understand the problem that we have to solve, and to help me understand where do I need to contribute.

Over the years I came to conclude that pretty much the only way to motivate people is to give them a challenge just a bit bigger then the one they have already conquered. As a result, I am working on understanding where everybody is in the organization, so I can help them select the right problem for them. I believe that it is much better to let people pick the work they are doing then to try to force it on them. Intellectual work is only getting done if the person doing it can fully engage in it.