• facebook
  • twitter
  • linkedin
  • instagram

Debugging the Development Process

by Taylor

28th December, 2015



Steve Maguire, author of Writing Solid Code and Debugging the Development Process

Debugging the Development Process is a book written by Steve Maguire and published by Microsoft Press
in 1994. I happened upon this book while moving offices in my company and noticed someone was giving it away. I grabbed it and have found that it has great advice, even if it was published in what feels like centuries ago from a technological perspective.

Steve is a former Microsoft manager (executive?) who has experience with the daily monotony of software development, and knows many of the ins and outs we all have experienced. While working at Microsoft he was recruited to save dysfunctional teams and thus gained many experiences relevant to developers in a large technology company. This in-depth industry experience serves as the backbone and basis to his classic software engineering guide, Debugging the Development Process. Note that if this book sounds interesting to you, Steve also wrote Writing Solid Code prior to publishing Debugging the Development Process and makes mention of this book several times.

Debugging the Development Process is a guide geared towards managers, with Writing Solid Code serving as the companion book for developers looking to write bug-free C code (back when it was fashionable to write in C!). Although Debugging the Development Process is geared towards managers, I’m not a manger in my current role, and I find it tremendously interesting and helpful. This guide can serve realms outside those of software development and will be useful to any manager looking to implement processes that increase the productivity of his/her team while increasing the quality of the products it releases.

The book is broken into nine chapters:

  1. Laying the Groundwork
  2. The Systematic Approach
  3. Of Strategic Importance
  4. Unbridled Enthusiasm
  5. Scheduling Madness
  6. Constant, Unceasing Movement
  7. It’s All About Attitude
  8. That Sinking Feeling


Laying the Groundwork

Laying the Groundwork offers some basic principles that all successful software developer leads keep in mind, or as I prefer to state, all successful software developer leads who wish to be successful should keep in mind. In a message that sounds like it fell straight out of Eric Ries’ book The Lean Startup, the first message Maguire delivers is that a lead’s job is to clear the way for the primary work (development) his or her team members. Anything that gets in the way of directly improving the product–daily meetings, detailed reports, etc.–should be eliminated. Managers should go out of their way to create detailed goals and priorities for the team so that each team member can identify which work is high priority and what is a wasted effort. This allows a greater level autonomy and an increased level of investment for each team member.

Stating your goals is an integral beginning on a road to success. How many people do you know wake up one day and realize they happened to have just the right physique for an NFL player, or just as miraculously had taken just the right number of courses to get a computer science degree? People don’t just become top-earning NFL players and college graduates. At some point they make a conscious decision, “I’m going to become an NFL player”, or “I’m going to work as a software engineer”, and then they do what it takes to make that happen.

This is the idea behind one of three central points in Maguire’s Laying the Groundwork, State Your Objective. In helping struggling groups, Maguire found that many organizations who had floundering projects often had vague goals. A great example he provides discusses a team inside of Microsoft that was in charge of providing a user-interface library to 20 or so other teams. The team was swamped and other groups using the library were complaining of the size an bugginess of the code. He asked the team lead what the goals of his project were:

To provide a windows-like user interface library for th MS-DOS character-based applications”

Steve was not satisfied with this answer as it was too vague, and upon probing more, the only additional, detailed goal he received from the lead was for the library to be bug-free.

Then he pointed out that the goal of the library was only to include features that all groups utilizing the library would need, and the lead said this was obvious, but Steve wasn’t so sure so he went through to review the list of features he had agreed to implement. Read the exchange below:

I pointed to an unusual item near the top of the list. “What’s this for?”
The Works group wants asked for that. IT allows them to…” he said.
“Is it useful to any other group?”
“No. Just the Works group.”
I pointed to the next item. “What about this feature?”
“That’s for the CodeView team.”
“And this item here?”
“Word wants that.”

As they went through the list of features it was clear that the lead was agreeing to implement every request that came in. He may have known that a library should conain only code that will be useful to all groups, but he wasn’t using that criterion in his decision-making process.

Had the goal been:

Goal: To provide a Windows-like interface library taht contains only functionality that is useful to all the groups who will use the library

Which is certainly more specific than that he listed previously, the lead would have seen that many of the features on his list to implement were inappropriate for a shared library.

Highlights

  • A project lead should ruthlessly eliminate any obstacles that keep the developers from the truly important work: improving the product. Any work that does not result in an improved product is potentially wasted or misguided effort. Shield the development team from any work that interferes with progress.
  • Established detailed project goals to prevent wasting time on inappropriate tasks. Don’t skip the goal-setting process simply because you think it would take too much time or because no one else sets goals. The extra effort you exert up front will more than repay you.
  • Establish coding priorities and quality bars to guide the development team. Every team member needs to know the coding priorities. Is maintainability important? What about portability? Size? Speed? If you want the code to reflect the goals for the product, you must tell programmers what trade-offs to make as they implement features. You must also establish quality bars so that team members won’t waste time writing code that will have to be rewritten when the product goes to ship.

 t

The Systematic Approach

The Systematic Approach is…you guess it…all about systems. And no, not systems engineering, not industrial grade main-frame systems, it’s about basic approaches to working that require very little work, yet can drastically (in a positive manner) affect the output of one’s work.Referring to one of these “systems”, Maguire states,

Ideally, the habit or process will take little or no effort to put into practice and its effectiveness won’t depend on the skill levels of the programmers who use it.

The chapter revolves around how to create systems that will elicit the outcome most closely aligned with a team’s goals. Part of that is narrowing down the question you ask yourself, or your team members to focus in on what outcome you really want to accomplish. An example of this may be:

“How can we consistently hit our ship dates?”

Something as broad as this leaves room for a variety of solutions that won’t necessarily be acceptable. For instance:

  • Hire more employees
  • Mandatory overtime for all the developers
  • Release the code as is (bugs and all)

A more appropriate question to ask when defining a system may be

How can we hit our ship dates without hiring more people and without working overtime?

This latter question will elicit a more thoughtful response and better solution than the former.

Another approach discussed is negative feedback loops. A negative feedback loop is a system that measures a variable, takes action on that variable based on the measurement (thus changes it), and then sends that variable back through the system to be read again.

Negative feedback loops enforce strict behavior of its subjects. An example of a negative feedback loop is forcing developers to fix bugs immediately as they are found before they can go on to develop new enhancements. Not only does enforce that all bugs are fixed immediately and promote good development practice (the less bugs you introduce the more enhancements you can work on) but also it is a huge cost saver. Data shows that the longer a bug goes without being found (or fixed) the cost to fix the bug dramatically increases.

This makes sense, as a developer still has the code that introduced the bug fresh in his mind so they don’t have to go back and relearn the code to sort out the fix. If the bug is fixed before it makes it to the testing stage, then the testers don’t have to go back and add this new test to all of their regression scripts. Before production, then the company saves time documenting and releasing information on the bug to customers, etc. etc.

My favorite part from this chapter is the section on coffee shops, which I’ll past in its entirety below.

A common problem for servers in coffee shops is remembering who’s drinking regular and who’s drinking the decaffeinated stuff. A coffee shop manager with unlimited time and resources might send all the servers to Kevin Trudeau’s Mega Memory seminar, where they’d learn to vividly imagine a calf with a hide that matches, say, the customer’s paisley tie, so that seeing the tie at refill time would trigger the thought of the paisley ca1f—and decaf coffee. Most coffee shop managers take a much simpler approach to the problem, though: they just tell the servers to give you a different kind of cup if you order decaf. The server need only look at your cup to know what type of coffee you’re drinking.

A trivial system for solving a common problem.

Now imagine a coffee shop that has a whole collection of such trivial ”systems” that produce better results with little or no extra effort. Let’s look at another example.

There are two coffee shops near my house. They have identical coffeemakers, they use the same supplier for their beans, and the servers in both places are college students. But one shop consistently brews great coffee, whereas coffee at the other shop is sometimes good, sometimes watery, sometimes too thick, and sometimes burned beyond drinking—you never know what you’re going to get when you order coffee there.

Circumstances at the two shops are identical except for one seemingly insignificant detail: the shop that consistently serves great coffee has a short horizontal line embossed on the side of each of its coffee pots. That short line is part of a simple “quality system” that consistently produces good coffee. When a new employee first comes on duty at this shop, the manager pulls him aside and gives him a short lecture:

”Whenever you pour a cup of coffee and the level of coffee drops below this line,” he says, pointing to the mark on the pot, ”immediately start a new pot. Don’t go on to do anything else before you start that new pot.”

”What if it’s really busy?”

”I don’t care if the place is filled with Seattle Seahawks an hour after they’ve blown a Super Bowl game. Start that new pot before you give Mad Dog Mitchell the cup you’ve just poured.”

The manager goes on to explain that by taking 15 seconds to start a new pot before the old one is empty, the server might make the current customer wait an extra 15 seconds but that the practice prevents the next customer from having to wait a full 7 minutes for a new pot to brew because the current pot ran out.

If you order coffee at the other coffee shop, it’s not unusual for the server to reach for the pot only to find it empty, and you have to begin that 7-minute wait. Of course, sometimes you don’t have to wait the full 7 minutes. To shorten your wait, some servers will watch until just enough coffee for one cup has brewed and pour you that cup. But for good coffee, you must let the entire pot of water drip through so that the initial sludge can mix with a full pot of hot water. If you pour a cup too early in the process, that cup will be so strong it will be undrinkable, and any other cups you pour from that pot will taste like hot water. That’s one reason the quality of the second shop’s coffee fluctuates. Depending on when your coffee is poured, you’ll get sludge, coffee-colored hot water, or sometimes even normal coffee. And of course occasionally you’ll get burned coffee—when the pot holds just enough coffee for one cup and there’s not enough liquid to prevent the coffee from burning on the warmer as the water boils out.

The only difference between the two shops is that in one they make coffee when their pots get low and in the other they make coffee when their pots get empty. Their systems are so similar, yet they produce drastically different results, and the results have nothing to do with the skill of the people involved. ‘

I wouldn’t be talking about these coffee shop systems unless they
made a point that related to software development. They do.

If I were to ask you if it mattered when in the software development process your team fixed bugs, provided the bugs were fixed before you shipped the product, what would your answer be? Would you argue that

the team shouldn’t focus on bugs until all the features have been implemented? Would you argue that bugs should be fixed as soon as they’re found? Or would you argue that it doesn’t matter, that it takes the same amount of time to fix a bug no matter when you get around to doing it?

If you thought that it doesn’t matter when you fix bugs, you would be wrong, just as a coffee shop manager would be wrong if he thought it didn’t matter exactly when his servers made new coffee. Possibly the worst position a project lead can find herself in is to be so overwhelmed by bugs that the bugs—not the goals—drive the project. If you want to stay in control of your project, one of your concrete goals must be to never have any outstanding bugs.

Highlights

  • Simple work systems can produce dramatic results. Take a good look at the processes team members are already following. Are there problems with those processes? Are they too time-consuming? Too error prone? Look for simple changes you can make to improve development processes.
  • Refine questions you ask as you look for solutions to problems. Develop the ability to ask precise questions to improve the quality of your answers.Be sure the question you ask focuses on what you’re ultimately trying to achieve. Don’t ask, “How can we get programmers to work longer hours?” Ask, “How can programmers get more done in less time?”

 t

Of Strategic Importance

Of Strategic Importance (unsurprisingly) focuses on: strategy.Merriam-Webster’s dictionary succinctly describes strategy as

a careful plan or method for achieving a particular goal usually over a long period of time

What is this “particular goal”? We mentioned earlier the importance of having a detailed set of goals for your project. These goals help managers determine what is in scope and out of scope for the project. It helps determine what aspect or modules are strategic to focus on. Those that are not strategic are those that do not fall in any or all of the criterion of the manager’s project.

In this section we are talking strategy to achieve a goal generic to all projects: keeping your work on track.

There will be more to come in this section, but for now, check out the highlights below.

Highlights

  • Don’t let foreseeable problems surprise you. If you want your project to run smoothly take time to look into the future. You can prevent many catastrophes by taking small actions today that either eliminate problems in the future or steer you clear of them. If you regularly ask the question “what can I do today to help the projects on track for the next few months?” You can determine the action you need to take.
  • Before you settle in to solve a problem, you sure you’re attacking the right problem. Get to the bottom of the problem before you try to treat it.

 t

Unbridled Enthusiasm

Steve talks a lot about overhead (without actually calling it overhead). A lead of a software team’s role is to reduce overhead. It’s to remove all facets of a team member’s job that does not directly improve the product. Of course there are some aspects of a job that are required, a team member still needs to report on the status of their work and the progress they’ve made on a regular basis, but it is a leads role to make sure the non-product focused work is reduced to the absolute minimum.If you haven’t gotten the jist from many of the points made in this book yet, a lot of it is about process optimization. I’m sure anyone reading this has had an experience in which they blindly followed a process they felt was a rude waste of their time. Chances are that it was.

As companies grow, so do their processes. Often times processes are put in place that are relevant and integral to a company’s success, and then as things change in the company, the process becomes outdated and irrelevant. Yet because people have forgotten the original purpose of the process, the process inevitably remains.

There’s a great story illustrating this phenomenon,

A young boy once asked his mother why she’d cut the ends off a pot roast before she put the roast into the oven. “Well,” she said, “because that’s what my mother taught me to do.” But the question got her to wondering, so she asked her own mother for the reason behind lopping off the ends. “To tell you the truth, I don’t know,” answered her mother. “I’ve always done it because that’s what I saw your grandmother do.” A real mystery. So the boy’s mother put the question to her grandmother. Grandma’s reply: “Back then I had a small roasting pan–roasts wouldn’t fit into the pan unless I cut off the ends.”

As you can see, back when the process was originally designed, it was required to successfully cook a pot-roast. Overtime the tools used (the roasting pan) were improved and the process was no longer necessary. In fact, it was an impediment to cooking an optimal dinner because cutting the ends of a pot-roast off wastes time (the time to cut off the ends) and resources (the uncooked meat that doesn’t make it to the dinner plate).

This is how a company’s policies become a barrier to its success, as opposed the opposite for which they were originally designed.

If a process is an impediment to success, remove it.

There are likely plenty of these in any company, even the smallest of businesses, and everyone in the company needs to make a consistent effort to remove or alter each overbearing process as they are encountered. Yet not all processes are overbearing and one that Maguire finds particularly valuable is hat of writing a project postmortem report.

A postmortem report answers the following questions:

  • What can we learn form the project we just finished?
  • What went right (let’s keep doing that)?
  • What went wrong (how can we prevent those problems from happening in the next project)?

These reports are crucial because they force the team members to actively consider how they can improve the development process moving forward, creating an environment of continuous improvement, at least in theory.

If the postmortem isn’t detailed, chances are it’s not going to be followed.

Take for example, the following postmortem:

The Bed Planning application accumulated a large number of bugs throughout the course of the project. This large set of issues prevented us from estimating our remaining work and ultimately caused us to miss our ship date by two months. Moving forward, the Patient Flow team will keep bugs to a minimum throughout the development cycle.

While that seems to be an adequate description of the problem, the solution is far to vague to have any teeth in the game. Often times reports like these will be written because they have to be, and then saved away in some obscure team folder, never to be looked at again. If that is the destiny for any report, it might as well not be written at all. Compare that postmortem report with the following:

By the time feature implementation was “complete”, the Bed Planning application accumulated 512 documented QA notes, 102 of which were classified as Important To Fix. While we were aware there were a number of bugs to fix, this elephantine issue list caught the team by surprise and caused us to miss our ship date by 63 days.

In the next development cycle, developers will be expected to squash bugs immediately as they are found. Josh Lindell has agreed to monitor do standard issue tracking and is responsible for ensuring our known issues remain under 4 issues per developer at each weekly status meeting. No developer will be permitted to work on a new project until the current project is determined to be in a shippable state. Should the team fail this metric then Josh will organize teams to bring the bug list into a manageable state.

With this approach the code which is causing the bugs will be fresh in the developers’ minds (making it easier to fix) and the bug list will always be in a manageable enough state to verify if we are on course to hit our ship date.

Which one do you feel is likely to have a bigger impact on the development process? This postmortem has a far more detailed attack plan. Even more importantly it has the characteristics of a successful plan:

  • Who: Josh Lindell
  • What: Keeping the bug list in check
  • When: Each status meeting
  • How: Creating a negative feedback loop by forcing developers to fix issues as they arise, and reorganizing teams as needed

You can tell the team met to discuss this postmortem, processes are going to be put in place, and everyone is on board.

Meetings

When I was up in middle school, my dad would drive me to school each morning. Inevitably he would call into a conference meeting, put his phone on mute, and listen. He told me there was around one hundred employees on the call, and yet I would listen and not once could I recognize more than ten different voices talking. My dad spoke only spoke a handful of times the entire school year.

Although I didn’t know what they were talking about, I knew one thing for certain, this meeting was a huge waste of time. If only five to ten people spoke for the entire call, then likely only five to ten people needed to be in the meeting. Ninety percent of the participants in the meetings were not participating. At best each idle participant was sitting by their machine documenting what was discussed. At worst, they splitting brainpower between listening, and some other pressing work that likely deserved full focus. If the information being discussed was relevant to the rest of the listeners, then the resulting decisions could be written up and sent via email.

Prior to scheduling a meeting, it is important to determine if meeting is really necessary. In page eighty-one, Maguire offers a few examples for which he feels calling a meeting is justified:

  • People must be able to ask questions or to interact with other attendees
  • Value is derived from seeing or experiencing something in person like a product demo
  • There is a matter too delicate for a memo / email–lay-offs and team reorganizing.
  • To reiterate the importance of a message. Meeting in person underscores just how important the message being passed down to the employees is.

Any of these reasons by themselves qualifies a meeting to be called. Unfortunately however, even after a diligent lead evaluates and determines the purpose of her meeting is valid, chances are that time still goes wasted.

Often times meetings are frankly a waste of time. They are disruptive to daily work. Recurrent meetings are particularly guilty time-wasters because often times participants don’t know why they are meeting. As Maguire puts it, “Are we meeting because its noon on Tuesday or because there are truly designs to review?”. If there is a recurrent meeting, say a Tuesday design review, I imagine the meeting will begin with “So, do we have any designs to review today?”. If this is the case, multiple participants have now disrupted their daily work, made their way to the meeting space, with the chance that there aren’t any designs to review.

This is incredibly wasteful to productivity.

So many times meetings with a valid cause for existing are not effective because the participants aren’t aware why they’re there. How many times has a meeting been thwarted because someone didn’t come prepared with a crucial piece of information or a key participant couldn’t show up?

The question Maguire aims to answer in talking about meetings is how can we get all of the benefits of meeting, without all the drawbacks?

The benefits in this scenario are the results obtained from the meeting, and the drawbacks are that time is often wasted, with little or no results to show for it.

When planning for a meeting, make sure to decide exactly what you want to accomplish at the meeting and then figure out how to get those results by the meeting’s end. If a key decision maker is not there or a piece of information is missing, it is better to make a conditional decision than to defer the decision altogether.

Imagine a time when someone failed to bring a required piece of information to a meeting (in this example an estimate for a completed feature). In this scenario it’s likely the individual running the meeting closed with something along the lines of, “George–figure out if your two week estimate for XYZ feature is correct and then we’ll meet again to decide if it will make it into this release”.

Highlights

  • Before calling any meeting, be sure you know exactly what you want to achieve and what you need to achieve it. Then make sure you do achieve it. Arriving at a conditional decision is better than arriving at no decision. If you hold a meeting that doesn’t end in a decision, that meeting is probably been a waste of time.
  • Try to limit the number of reports you ask other team members to write. Be sure that ever you’re poor you ask for provide more value to you or the company and would be lost by interrupting the writers work.
  • If you must hold a meeting minimize the amount of in a rush and it will cause. Scheduled a meeting so that it won’t break up and otherwise large block of time.

 t

Scheduling Madness

Scheduling is important. A schedule serves as a roadmap from idea to product with deadlines along the way. It can be motivating or it can be overwhelming. The key to creating a great schedule is to create one that is aggressive and yet not unattainable.

What if I were to tell you a great way to schedule a due date, particularly in software, but generally any large project, is to make a complete list of tasks, assign time estimates and then determine the corresponding due date based of the sum of each individual task.

Sounds logical, right? Except 9 times out of 10 this isn’t going to work. In fact it will likely cause more problems than it solves.

For one, having a complete task list, each task containing a corresponding deadline, for a multi-year project is quite daunting.

There are always going to be tasks that go unnoticed and undocumented, and the larger the scope of the project, the greater in quantity these unnoticed tasks are.

As the weeks go by, team members are likely going to barraged with deadlines that didn’t take into account the complexity of the project and those that are simple unattainable. At best, they will have their egos torn down. At worst, the entire team could suffer from what Maguire calls “slipsteria” — essentially a frenzied attitude of outstanding and overdue tasks that consumes them and causes them to “finish” their buggy projects in order to move on to the next soon to be buggy project.

Maguire points out that often times many deadlines are fairly arbitrary. In a meeting among higher ups, it could simply be one manager’s estimation that decided the deadline for the entire project. In less forgiving deadlines, Maguire is quick to point out that a few weeks of a delayed release data, while in no way a good thing for any company, is going to cause less of an issue downstream than releasing buggy code to please the deadline.

Additionally there is going to be an inherent time associated with bringing each of these tasks together.

Highlights

  • A schedule can have a devastating effect on a project if it creates slip-hysteria and causes team members to make bad trade-offs un order to hit arbitrary deadlines. If you create a schedule that has unattainable goals–in hopes of extracting as much overtime as you can from each developer–you’re creating a situation that will demoralize the team, and team members will look for work elsewhere once the project is finished.
  • By using project milestones instead of task lists to schedule, you can shift the focus to completing subprojects, which creates “wins” for the team and emphasizes progress. If you space the milestones approximately two-months apart, you can create a sense of urgency that will help people stay focused–especially if the milestones have strong, exciting themes. Try to create milestone subproject goals that result in the team’s thinking “Wow! Look at what we’ve accomplished!”

 t

Constant, Unceasing Movement

“Records are made to be broken. It is in man’s nature to continue to strive to do just that.” — Richard Branson

Each Olympics another record is broken. The 400-meter individual medley world record was set by Michael Phelps in 2008. He completed the race in just 4 minutes and 8.26 seconds. In 2009, Usain Bolt set the record in the 100m sprint, clocking in at 9.58 seconds. Why is that? 

Is it because humans have evolved over time to outpace their predecessors. Likely not as the timeframes we are looking at are far too short for evolution to have a tangible impact.

The reason is due to a drive for continuous improvement. Each year runners, swimmers, skaters and other athletes raise their standards as they try to claim the title of world champion. Athletes 25 years ago were likely capable of achieving the same accomplishments that the Phelps and Bolts of the world, but they didn’t, because they didn’t have to. They achieved what they needed to to be “the best” and nothing more.

The drive for continuous improvement is the central focus of this chapter. Maguire discusses strategies to ensure employees undergo continuous improvement throughout their career, raising the quality and expectations of the “average” programmer in the company.

Once a programmer reaches the “average” threshold, the pressure to continue learning eases up, even though the programmer is likely capable of much more. This is not unlike the athletes of yore that achieved what was required to be the best and nothing more. Having a programmer accomplish simply what is expected is not good enough.

An effective team lead perpetually raises the standards. As the standards for an individual rises, so will that of your team, and eventually the whole company.

Raising the standards may take on whatever form seems most appropriate. In my company, raising the standards may consist of bringing down the number of known bugs per developer. It may include increased emphasis and critique on design and user experience, or even the rate of development.

Stagnation

A integral aspect of continual improvement is constant learning. Maguire discusses this phenomenon in detail throughout the chapter.

(Note: Follow a similar example in the book p. 109.)
Consider two programmers who both started at the same time working on the same project, the company’s file converter software. The goal of the project is to write filters to read and write the file formats of competing products. Both developers worked on this important area of the company for the first year of their career. After a year writing file filters Sally transitions to other areas of the application, and Liz continues to write filters. Maguire states this eloquently by noting that five years into her career, Liz would claim that she has had five years of development experience. Maguire points out that this is really one year of development experience, five times over. In those five years Sally has moved about the company and learned a wide variety of skills. At the end of their fifth year of the company, the two employees’ portfolios look like this:


Liz
  • Converter Specialist, can convert between a number of file formats:
    • .doc
    • .txt
    • .xlsx
    • .odm

Sally
  • How to convert data to other systems. Can be something simple such as clipboard to .txt document, or more complicated proprietary document format exchanges.
  • How to internationalize software, including dealing with double-byte characters, tokenization, locale-specific formatting and text orientation.
  • Interfacing with printers, can write printer plugins, architect reusable components for use of printing various user interface objects and debug complex client / server communication.
  • How to use the graphics library to draw shapes, handle color palettes, convert between various color formats and plot bit maps.

Say you’re starting a new team in the company, who would you rather have? While Liz undoubtedly has had more experience in writing file converters, Sally is also familiar in the area and has vast experiences in other areas.

The challenge for many managers is that once someone becomes an expert in an area on the team, any time the manager delegates assignments, they will be naturally inclined to assign the expert the task in their area. It’s not until employees like Liz threaten to leave their projects (or worse, company) in search for more interesting work that the lead starts to delegate new and exciting work to that person.

As Maguire quotes in p. 111, many managers react to this philosophy like so:

If the specialists aren’t doing the tasks they’re expert in, wouldn;t they be working more slowly on tasks they know less about? Don’t you waste time by not putting the most experienced programmer on each task?

The answer is yes and no. But mostly no. If you assign someone that is not the expert a task in a particular functional area–say printing–yes the task will inevitably be done slower than if the expert had worked on it.

However if you look at it from the perspective of the project as a whole so that you’re constantly training team members to be proficient in all areas of the product, you will have a much stronger team. In this team, any member can fix any problem that comes their way, you don’t have to rely on the expert to fix some new killer bug.

An even greater time-saving benefit of this dynamic is that all employees now are familiar with other subsystems, which means they will reduce the duplication of code and you will improve the overall product-wide design.

You may be losing some time during the initial development as your team members learn new skills and gain experience, but for each minute spent learning a new skill, you’ll save several multiple minutes time and time again as the use that skill.

Constant Improvement

Every company I’ve ever been at does an annual review. In this time managers often tell their employees something that they could have (and should have) told them 6-12 months ago. The problems in performance that the manager brings up at the review are typically something the employee has not been made aware of. In shock, the programmer will ask–can you give me an example of this?! The manager fails to come up with anything or finds something that seems ridiculously out of proportion in the context of the last review period. Then the employee becomes upset, feeling cheated and the meeting ends. Later the programmer likely thinks, “why didn’t she tell me something was wrong, rather than waiting a year? I can’t fix something if I don’t know it’s wrong.”

Steve gives a humorous description of this problem below (p. 121):

What if coaches waited until the end of the season to tell players what they’re doing wrong?
“Mad Dog, I’m putting you on the bench next season.“Huh? What? I thought I played great,” says Mad Dog, confused.
“You played well, but at each snap of the ball, you hesitated before running into position.”
“I did?”
“Yes, you did, and that prevented you from catching as many passes as you could have. I’m putting you on the bench until something changes. Pf course, this means that your yearly salary will decrease from $5.2 million to $18,274. But don’t worry, you’ll still have your benefits–free soft drinks and hot dogs at the concession stand, and discounted souvenirs.”Mad Dog, particularly mad now: “If you spotted this, why didn’t you tell me earlier? I could have done something about it.””Hey, I’m telling you now, at our end-of-the-season contract review.”

Sounds kind of silly doesn’t it?

Highlights

  • Never allow a team member to stagnate by limiting him or her to work on one specific part of your project. Once a programmer has mastered an area, move them to a new area so they can continue to grow their experience and improve their skills.
  • Skills vary in usefulness from those that can be applied to any project to those that can be applied to only one type of project. When training new team members, maximize their value to the company by firt training them in the most widely useful skills and save project-specific skills for last.
  • To ensure that the skills of the team members are expanding on a regular basis see that every team member is always working on at least one major improvement goal. The easiest approach is to align growth goals with two-month milestones, enabling at least six acquired skills or skill enhancements each year–which is six more than many programmers currently experience. If Liz, the file converted specialist had read just six high-quality technical books a year–after her first five years she’d have read thirty such books. How do you think that would have impacted her work? What if she instead read fifteen and the mastery of fifteen valuable skills over the first five years?
  • The best growth opportunities emerge from a strong, immediate need. If you find a team member working inefficiently or repeating the same type of mistake, seize the opportunity to create a specific improvement goal that the team member can act on immediately. Since this was given at the opportunity for growth and needed to solve a specific problem, the programmer is more likely to take action on the growth goal than if it were given at the annual review.

 t

It’s All About Attitude

Many programmers believe that bugs are an inevitable side effect of new development and there’s nothing you can do but fix them once they are discovered. A co-worker of mine once described his plan for the next two weeks to our boss and me as “finish the project, and then spend the rest of the time fixing the bugs that Quality Assurance finds in the project.” Our boss did not deny this may be the case, but he pointed out that these bugs should not be seen as inevitable. I agree.

In fact, programmers can do a lot to reduce the amount of bugs they introduce, and it begins with changing the attitude that writing bug-free code is something that is critical to product development and an achievable goal to obtain.

One simple–and obvious–technique that can be used to catch bugs is to turn on optional compiler warnings and to use linters.

Some of the suspicious–and likely to be bug-inducing–constructs that can be caught with these optional tools are:

  • Variables being used before being set
  • division by zero
  • conditions that are constant
  • calculations whose result is likely to be outside the range of values representable in the type used

An example of an error caught by a linter would be the following:

var string1 = “Hello, Taylor!”
var num1 = 5/0;
string2 = string1;
num1= num1+5;
console.log(string2 + &quot:&quot + num1);


Above there are a couple of suspect constructs above. Some of these are caught by our editor, and some are not. A linter will throw errors on suspect code constructs even if they are not syntactically incorrect. An output of a linter might be something along the lines of the following:

Line 1: Missing semi-colon.
string1 is assigned but not used
Line 2: Cannot divide by 0.
Line 3: “string2” is not defined.

Even if you’ve got great habits and the linter isn’t ever going to find anything for you to fix (unlikely), it never hurts to have a little positive reinforcement now and then:

No errors found!

Adding tools like these to your development process little to no effort from your programmers, and yet eliminates a whole class of bugs.

Other attitude problems that can lead to substandard products:

  • It’s good enough for users.

    Programmers that think the end user is dumb, or has lower standards than that of the programmer themself. This is often untrue. In fact, the use is more likely to be concerned about speed and usability than that of the programmer.

  • It can’t be done. It’s impossible.

    Can’titude (or resisting effort) is a poisonous attitude on the team. Often times anytime someone states something cannot be done, they likely have not spent the time to give it a thorough analysis. They just state “that’s impossible” immediately upon hearing the idea. Said to a manager, this typically means, “that’s too hard”, and the employee is not up for the task. Programmers should be under the impression that anything is possible given enough time and effort. If this is proclaimed in front of a group or to another employee, this attitude can very quickly stifle creativity and stretch goals of the product. Employees with big ideas will learn not to share them for fear of feeling stupid. End this attitude as quickly as possible and make sure developers understand the problem and understand that almost anything can be accomplished if the time and effort is invested in solving it.

  • Highlights

    • Novice programmers must understand how difficult writing bug free code is. If they understand that, they won’t readily assume that their code is bug-free. More experienced programmers must understand that even though writing bug-free code is difficult, it doesn’t mean they should give up trying to write such code; it means that they must spend more time testing their code up front, before the code ever reaches the quality assurance team.
      Because it’s so difficult to write bug-free code, and so costly when bugs make it into the master sources, all programmers must use every tool at their disposal to detect and prevent bugs, even if that means adjusting their coding styles to conform to best practices.
    • Watch for the “it’s too much work” and “it’s too hard” reflex reactions. When someone objects that a task will take too much time or that it will be too hard, ask yourself if the individual first considered whether the task was important and whether it matched the project goals and priorities. If it seems to you that he or she was merely responding reflexively, try to refocus the person on the merits of doing the task so he or she can evaluate the idea freshly and fairly.
    • Teach programmers to view the product a an end user would. Programmers must recognize that end users view everything that goes into the box as a single product. Users shouldn’t care how the pieces got into the box, they don’t care if the product as built by 27 different teams, they don’t care what language it was written i, etc. Programmers and leads should be concerned when any piece doesn’t meet the quality standards set for the product.
    • The attitude that the user is neither demanding nor discerning (ie, dumb) is a detrimental one. Whenever you hear team members expressing such views, remind them that users-who by definition actually use the product, are at least as concerned about speed and the other aspects of software quality as the programmers who write the code.
    • A common tendency is for people to think negatively when they’re faced with something they haven’t done before. In some form or another they latch onto the idea that the task is somehow impossible. Try to shake up this habitual response and instead help team members instill the idea that most tasks can be done if only people would take some time to think about them.

      It’s amazing how often you can respond to a “can’t” judgement with the question, “I realize it can’t be done, but if it could be done, how would you do it?” and hear people rattle off exactly how they would do the thing they just said was impossible.

     t

    That Sinking Feeling

    I’ve not yet finished my writing on this chapter of Maguire’s book. Please see the highlight’s to get an idea of what is discussed.

    Highlights

    • You can minimize meetings, reports, and other corporate processes, but unless you also focus on the wasted effort unique to each individual, you’ll be missing a significant part of the problems you need to work on. Make it a priority to help each team member design large blocks of uninterrupted time into his or her daily work schedule.
    • If you care about your team members don’t allow them to spend all their waking hours at work. Make sure they work a solid eight hour day, and then kick them out. Taking that stand at your organization may seem sacrilegious, but if you believe, as I do, that people work better if they have an enjoyable personal life, take that stand.
    • There’s nothing secret about the 40 hour work week. It’s a US tradition, so suffer projects 10 rescheduled on the assumption that each programmer Will work a 40 hour week – five 8-hour workdays. If it takes a lot more than 40 hours per week for programmer to meet one of these schedules something is wrong. The schedule might be unrealistic, or the programmers might need more training. Either way there’s a problem that needs to be fixed – not mass batting programmers work long hours to compensate for the problem.

    [no_toc]


by Taylor