numbersA software developer in California (I’ll call him Miles) wrote to me recently with a question about motivation. Instead of answering right away, I asked if I could pose his problem to all of you. Perhaps by combining our minds, we could be a free open source McKinsey & Company for motivation.

So here’s Miles’s question for us:

“How would you motivate a software team to reduce bugs in a product throughout the development process instead of just the end?”

And here’s my question for all of you:

What should Miles do?

Offer your answers in the comments section. I’ll weigh in with my own thoughts. And in a week or so, I’ll post our common solution.

63 Responses to “What should Miles do?”

  1. Ed Brenegar says:

    He needs to leave that decision to the developers.
    Focus on the big picture.
    Set standards and a time for the first complete version to be done.
    Stay in touch, be helpful, facilitate whatever team problems develop, but leave let them do their work without distractions.

    Now, if he doesn’t trust his developers, then that is a different story.

  2. Totovader says:

    I’ve always been a fan of explaining the 1:10:100 rule- not just in terms of saving cost, but also in saving energy. I have a feeling that if these developers could understand that they can save their own frustration by doing debugging during the project instead of just after deployment- then you might not need to have to motivate them at all… they will be motivated themselves to do it right. You can help them realize that in a time tracker / incident tracking system: see how much of the work is re-work or fixing bugs that could have been fixed in development or even in planning.

    Part of it is the developer mindset: do it fast and do it good enough to pass the test. Anything else is usually just seen as extra work- no matter how satisfied the customer is. I think that’s because the focus is sometimes on the individual tasks that need to be done instead of the customers satisfaction. Developers compartmentalize their tasks and their job because that’s how coding works and that’s what they’re used to.

    If you don’t have time to do it right, how are you ever going to have time to go back and fix it?

  3. Dan Murray says:

    Hire good developers who care about the work they produce.

  4. Kwame says:

    He needs to set a vision for the project and then get the developers to buy into a bug free vision. maybe even have a mantra about it.

  5. Rands in Repose just had a fantastic blog entry on this EXACT concern: http://www.randsinrepose.com/archives/2009/11/29/up_to_nothing.html

  6. I don’t understand why they wouldn’t want to do this, so I probably first would spend time conversing with them about they view bugs, quality control, etc. to learn more. If they believe it is most effective to reduce bugs at the end, I doubt many incentives would help shift their approach.

  7. Scott Smith says:

    To say hire great devs is fine, but doesn’t help him now. I think Miles is looking for intrinsic motivation. Why should his devs care about bugs three months before release?

    I’ll assume they use a ‘cvs’ of some sort, so Miles could set the rule that whomever breaks the build, builds it until someone else breaks the build (isn’t that standard in big shops like Microsoft, Oracle, Sun, etc.?).

    Perhaps pair programming would build comradery — maybe even a bug review that isn’t intended to slap devs around but to build them up, increase their confidence.

    If part of Miles problem is distrust between devs and the company, buying them new hardware every 10 to 14 months can forge a better relationship. Geeks like killer machines, two or three incredible LCDs, multiple machines, Aeron chairs, and an environment that does remind one of county jail.

  8. Dan Ward says:

    I concur with Dan Murray – it starts with hiring. Preferably a small team. Big = more counterproductive politics & game playing

    And then listen. Treat the people like grown ups. Tell them your concern. Ask the question. Ask it again. Listen again.

  9. Dan Pink Dan Pink says:

    Great comments so far. Very insightful and productive.

    My first thought here was to question whether reducing bugs throughout the process is *necessarily* more effective than doing a massive sweep at the end. Maybe there’s a method to the developers’ apparent madness. Maybe it is, maybe it isn’t.

    Regardless, merely asking the question to these developers involves them in the process, supports their autonomy, and might help them get better at their jobs. That’s a good start.

    Let’s see what else we hear.

  10. Amber Shah says:

    Fixing bugs during development has multiple advantages over leaving them until the end. For one, you might have to drop important features from the release or release buggy software if you don’t have time to fix all the bugs before your scheduled release (or push the release date, all bad). Alternately, if you truly complete features in order of priority, you ensure that the most important features are included. Another benefit is that the customer may (and often does) want to change a feature once they see it in action, fixing bugs at the end ensures that they won’t have time to improve the feature. Then there’s the cost it takes to dive into a feature once to make it wrong, then to dive in again to re-do it. To build great software, you need to iterate quickly and release often.

    As far as what the team needs, it sounds like they definitely need automated tests. The fail the build. Wait, they probably need a build first. Ok, just start here: The Joel Test: 12 Steps to Better Code (http://www.joelonsoftware.com/articles/fog0000000043.html)

    As far as motivation, they need to understand the impact of what they’re doing and want to improve. Our deadlines get pushed due to bug fixes, let’s move them up. Bugs are getting released to the customer because we wait too late and then can’t get enough testing in. Regression bugs creep into the software because we don’t have automated tests. The customers are unhappy with the feedback loop because they only see it working at the end. If you have these problems and they see them, then they get start getting invested in the aforementioned solutions.

  11. Richard says:

    Implement Agile Scrum – you have a finished product every x weeks, usually two, that has to be deliverable and working.

  12. Gaurav Sharma says:

    Give them more time to think.

  13. George says:

    Easy. Figure out what already motivates each member of the team. Then, link that motivation to a process that removes bugs during development.

    For example, suppose one person is motivated by rules and processes in general. They like everything to be systematized and hate it when people do things ad hoc.

    I would sell this person on how a system can be used to catch bugs during development. I might say, “I wonder how we can improve our process to reduce bugs during development.” Then, once they become interested in figuring out how to make it happen, I would empower them to implement improvements in the process.

    Each person is probably motivated by something different, so I would use a different approach with each person.

  14. Elad Sherf says:

    This does not sound to me like a problem of motivation but a problem of everyday incentives. In that I mean that the employees probably know what is good for them (and as people here said before, I would talk to them about it), but have an irrational tendency to leave everything for the last minute. Thus I think an approach of creating processes as per Jule Kucera’s approach (http://tinyurl.com/y8cz5jj) and similar to ideas Dan Ariely offers in his book on how to create positive connection with behaviors would be more beneficial. Thus, I would try to create within the boundaries of autonomy a daily/weekly time that is dedicated to this. Maybe by creating something like a debugging room that everybody has to sign up for in advance every week. you could think about some kind of positive recognition type reward that will be associated with the room, but setting the pre-determined time by itself should prove to help a lot in solving the problem.
    Elad

  15. Alan Saporta says:

    I like George’s comment in general. Here’s a specific technique that I witnessed as effective. It may sound harsh and it’s rarely used but make all the developers be testers at the end of the cycle.

    I worked at a company that did exactly that. We used automated testing until we got to our first release candidate and then we went through about 3 months of practically the entire development team turning into a full time QA team (with a rotating ‘bug fixer’). The less bugs in the code the faster the QA cycle was and the quicker we could all go back to development since we hated testing. (The last comment is by no means a reflection on the incredibly important discipline of Quality Assurance). It’s a kind of “eat your own dog food” approach.

  16. Jerret says:

    Find the person who likes to debug. He/she is in their somewhere. Hopefully it’s someone that’s trusted by everyone else.

    Make him the debugging “king”. That’s all he has to do–find and kill the bugs. Hopefully others will see his passion and give him the most complex puzzles (i.e. code with small bugs).

  17. Matt says:

    There is a lot of focus on how to reduce the number of bugs in code. This question actually makes lives easier by trying to reduce the bugs as you go along. The best solution I’ve seen, by far, is when the QA group is involved from the start. At the end of the day, no matter what, the developers have a new build for QA. At the same time as the new build handoff, QA provides the list of problems they found. The big key to this method is getting the full QA test cycle down to 48 hours (or at least the planned feature/regression tests for that component). This highlights the existence of bugs early on, and allows each group to do what they’re best at.

    Now, if there isn’t a dedicated QA or testing group, getting people set up to do the actual testing (that were uninvolved in any of the code writing for that release) will go a long was.

  18. Matthew Hoyles says:

    I have never met a developer that likes to produce buggy or low quality code. Rather the opposite: producing good quality code is one of the main internal motivations for programmers, and external factors preventing this lead to poor motivation.

    Bugs at the end is the ‘waterfall’ method of producing software, which was the standard method for many years, and is still assumed in many contracts and corporate procedures. It is risky for the reasons Amber Shah gives. The modern ‘incremental’ or ‘agile’ methods use short build cycles, automated testing, and continuous feedback from the customer or users. These techniques involve fixing bugs (and doing everything else) throughout the process. It is a different way of working and requires support from management, users, and developers to be successful.

    So we may be talking about a culture shift here, and it it may involve more than the development team.

  19. The way Miles asks his question implies that the current method is to write code first, then do a testing and fixing phase at the end of a project.

    In general, a waterfall-y process like this does not work well for software development. Experienced software developers tend to know this; growing software is easier if it’s kept in good shape all the time. But even experienced developers tend to do what is expected of them, not what they think is best.

    So this might be a process problem and not so much a motivational issue. My suggestion is to introduce a software development process where the team is responsible for shipping high quality software in (potentially shippable) monthly iterations.

    Set the expectations, responsibilities, and power where they need to be. When everyone is expected to ship high quality code continuously, and have the power to do so, it’ll happen.

  20. Brysmi says:

    Fail often and early so you know where the blood is coming from. Ensure that no one is afraid of seeing some blood and guts.

    Some good advice here already, btw. This relates to a lot of what is being said: Hired well, the devs already know *how* to create quality software, but they have to know *why* … set the business context, let them define process. “We’re going to take that hill because {strategy and derived goals here}. How can you make that happen? What can I get you that you don’t have that will make it possible?” That is a fundamental belief I have about leadership and management — they are there to remove obstacles and set context. Also, most things they state are best done so in the form of questions.

    Also, define what a “bug” is, and get agreement on that. Talking about bugs to me means talking about quality, so it is best to define what quality really looks like. In keeping with that, make sure QA is always present and part of the entire development process — they are in the scrum in my world.

    Personally, I recommend asking for an iterative, agile methodology approach, fit to the team, by the team — have the team(s) take their pick. Put the team in close proximity to increase opportunities to communicate and increase the chances that no one is out of the loop.

    Minimize work in progress, for all the classic reasons — in software dev, this often means making sure that something is getting handed off to testing very frequently. If you have 5 engineers, for example, don’t have them working on 5 different deliverables that all get handed to testing at the end of a cycle … they are going to be late, ALWAYS, which is fine so long as test isn’t put in the bind of having too much to test with no time left.

    Keep the work batches small and functional as much as possible — as much as you can, always have shippable (or at least demonstrably functioning/improved software coming out in each iteration. If you start falling behind, find out sooner rather than later.

  21. Brysmi says:

    Oh, and as far as a big sweep at the end … I work with a team of 3 devs and 1 tester on a codebase we inherited that is close to 30k lines of code. It’s my understanding that a single dev can be familiar with about 1/5 of that amount of code … we’re not going to remember 50% of our software when bugs show up later … and so, when I get a bug that I wrote 6 weeks ago, it’s going to take me some time to re-discover the context and intent behind the decisions I made a long time ago.

    Or put another way, would I feel better if Boeing started testing planes after they were put together and presumed flight worthy, or do I want them to have been testing everything the whole time they were building it? Which approach invites corner-cutting incentives?

  22. John Zimmer says:

    OK, I am coming at the question from a completely non-tech perspective as my background is in international relations and law. However – full disclosure – I am reading an advance copy of Drive and I have seen your recent TED Talk on the subject.

    So, how to motivate Miles’ team? Some thoughts:

    1. It will be easier to motivate them if there is general recognition of the fact that fixing bugs at the end of the process is (or often can be) a time-consuming process. Some will likely agree with this statement, but for those employees who don’t, perhaps Miles has some information as to what percentage of total time the bug-fixing part comprises.

    2. Pitch the idea to the team before starting the relevant job. Let’s say a new contract has just come in. Meet with the team beforehand, discuss the job, and then say that we are going to use this job as a test case to see whether fixing bugs throughout the process results in more efficiency and a better product. That way, everyone is clear about the objectives at the outset.

    3. Make them feel involved. Miles should tell is employees that he wants their feedback and input. In my years of experience managing people, one thing that people value very much at work is to be listened to and to feel that their opinion counts. If the programmers feel that they can help steer the company’s procedures going forward, they will feel like they have ownership in the idea and will likely be more enthusiastic about it.

    4. Offer a reward. Now I realize that I am on thin ice here given all the research that you have shown about how incentivizing creative thinking can backfire; however, handled carefully, I think it could work here. I don’t suggest that Miles offer more money. However, if it is found that fixing bugs during the process results in a better product being produced in less time, then he could, after the fact, give his employees a certain percentage of their work time to think about how to implement this initiative throughout the company – I have no idea how big the company is – or even to work on other productivity-enhancing ideas for the company. Again, this ties in with the idea above about stimulating a real sense of ownership in the process and company.

    I look forward to seeing the common solution. Merry Christmas and a happy and successful 2010 to all.

    John

  23. J-F says:

    Does the task of checking for bugs after a piece of software is written require the same skillset as creating the software in the first place? Maybe it IS a task better done after the fact, and possibly by different team members. So motivating creators would be a real challenge in that. Going the “Strength” route here…

  24. Anjali says:

    Fron the banking industry, I can suggest the following. The bugs are not important, it is making the sale that is important. This generates the immediate cash incentive. After that, we place a bet against the software through our trading desk. If the software fails,we generate enormous profits, more than the stupid software ever would have made.

  25. Kimba Green says:

    I agree with John Zimmer. He hit all the right points. There is so many different ways to run a project but the most important is the *buy in*. If expectations are laid out, you listen to how the team can meet these expectations and have a reward for the job well done that will set everyone up for success. Communication is the corner stone!

    Great idea Daniel! Now we all feel like we have participated and helped Miles! Thanks!

  26. I think it was the author Patrick Lencioni who said “Weight in is a prerequisite for buying in.”

    Too often managers approach getting buy-in by trying to sell people (who often aren’t shopping) on their ideas.

    Input is the route to go.

  27. Keith M. says:

    I’d focus on the empathy piece to appeal to the emotional rational for why care should be taken throughout the development process. Locate end-users (customers) who have been negatively impacted by buggy software and make their stories available to the team members who are writing the code. Create a personal connection between their work, the final product, and the users of the product.

  28. clarke ching says:

    This isn’t a motivation problem! Rather, the problem is with the design of the software development system. Developers, like virtually everyone, want to do a good job; they don’t want to produce buggy code. It sounds like Miles is using an old fashioned (but very common) waterfall approach which forces testing (feedback) to the end of a project where it is difficult and expensive to rework any problems found.

    Miles will find that quality will go up, projects will finish sooner (and cost less), and his developers will start to enjoy their jobs more if he changes the system, rather than blames his developers for being unmotivated.

    How should he change the system? He can find most of what he needs by Googling “Scrum”, “Agile” or “incremental software development”. He could also take a look at my (free) business novella “Rocks Into Gold” at tinyurl.com/rocksintogold (it takes about 20 minutes to read). Put simply, the new approach, involves delivering 1 big project as several smaller projects. It’s a far simpler and easier way to work.

    Great question Dan! And, I’m still loving your new book…

  29. Chris Ungar says:

    In a quick and dirty and possibly pragmatic solution, point out that the more they fix in the development phase, the more reward they will have at the end. It would, however, cost the company either time or money or both.

  30. If the software has an architecture problem that introduces bugs when a piece of code is fixed, you will want to make sure you have a solid architecture in place. Application architecture frames development in a way that will makes software development easier for everyone.

    Also agree with the suggestion to use Agile, test driven design, or Scrum as a development approach. Interesting that Agile uses stories to describe features.

    One other suggestion: With each testing cycle, identify the developer who had the most bugs. That developer will have to create the software build for the next testing cycle and load the software on the server for testing.

  31. Chris says:

    Interesting subject, and one I’ve seen fail far more often than succeed. In the category of “fail”, I include those projects where the end product actually works but the process has left a trail of tears and blodied bodies. When it works, it has been because of three factors:

    1) A solid architecture and high level design, one that has enough substance to know that this will work, but not so cemented that it cannot accommodate the inevitable course corrections. This has to be the responsibility of someone who has this sort of successful experience.

    2) Proper tools are in place – configuration management, code control, test frameworks, useful simulators, etc. Anyone can throw a bunch of these OS components together but if they are well thought out and harmonious, developers will naturally gravitate to using them because they make their life better, and stay out of the way of actual design and development.

    3) Developer interest. One of the first things I do is find out what areas appeal to each team member and slice the project up accordingly. Nothing motivates software types like getting to work on a good chunk of stuff that lights them up. And they will track down the bugs naturally due to professional pride.

    When I have the opportunity (not always) to orchestrate using these principles, it never fails. This isn’t rocket surgery, if you have some basic understanding of human psychology.

  32. Gill Potter says:

    I’m going to have to agree with Clarke. Look at Agile and Extreme programming. I have also found that putting programmers in teams of two, one to write the code and one to look over the shoulder to catch mistakes. Switch often and build often. This is the only way I have found to reduce bugs while still delivering. Also, it has the added ability to keep everyone on the same page about the development process. The motivation to produce quality work is reinforced by constant feedback on that work. That is typically impossible in standard development processes.

  33. David Zinger says:

    Daniel:

    I’d change the question from motivation to engagement. It is not about motivating in 2010 it is about engagement.

    Get everyone on the same page by having the team write some of the page. Help everyone understand the importance and listen and act on what people offer. Make use of personal, social, and structural influence. Give everyone a ton of feedback or have everyone generate feedback.

    And of course you could create a giant golden bug pin to give the person with the least errors a great recognition token — okay, just kidding on the last one.

    David

  34. K-R says:

    Being in education, and having had two big programs implemented in our district just this past year that have been both difficult for staff and students, one in reading and one in grading, I think developers need to need to see the end result. They need to see how frustrating it can be when, after appropriate training, teachers sit down and try to add grades to a program that was not clearly designed for them and that had bugs in it. They also need to see what happens when a program has been set up for students to take analytical tests on and when students sit down to take the test, they cannot access the website.

    Part of developing and creating any product should always be to test and evaluate it in the field. We ask students to evaluate their work see how it applies to the real world. Should this not be the case in the real world?

  35. Examining the Agile/Scrum approach to software development might be a helpful approach – because it encourages developers to consider how their contributions affect the big-picture of the product. Furthermore, it allows the client (or manager, or contact), to see results as they appear.

    Often bugs aren’t problem with the code – but miscommunication between what the client desired, and what the best-guess solution was by the developer when that desire wasn’t documented – having short release cycles allows the client to catch communication errors early on, and minimize the time it takes to fix the issue.

    But also, software developers in a waterfall environment tend often to be rather isolated – they go into a room for a few months, and finally deliver a product. When the client (or manager) doesn’t take an interest, it’s easy to allow bug-fixes to fall by the wayside, because it’s more challenging to take pride in work that, frankly, may never see the light of day.

    Offering shorter release cycles allows developers to take pride in their work, allows clients to help point out errors in documentation or understanding of the problem, and makes both parties feel valued as contributing partners to the project.

  36. Software development is a team effort. A team, is not only the developer…but involves also the project manager, tester, key user, stakeholder.

    A lot of times I see companies introduce very complex developement processes. Why? Improve code quality and reduce the number of bugs. By implementing Agile methodologies (Scrum, XP,…), Test Driven Developement,etc.

    I’m pretty sure that by keeping your proces simple and straightforward, you could produce better software! It’s all about motivation and believing in the application you’re writing! I really don’t think that by looking “for the guy who produced the most bugs” or “who broke the build” you will improve the team collaboration or motivation.

    All in all, software should produce “added/business value” for the enterprise. So let your TEAM understand the value of the software you’re all writing…WHAT will it improve and HOW. Let them believe that the application will provide the wright solution!

    Just my 2 sense

  37. Phil Downs says:

    Why not treat them like our far-sighted politicians want to treat teachers. Set a date and run the program. Tie their wages to the results of the test run. Good programmers would receive a bonus and bad programmers would be made to undergo training or be fired. The logistics of this plan be damned. Don’t whine to me about all the factors involved…it sounds good.

    Why must we always be looking for simple solutions? Reality: these issues are being fixed somewhere through hard work and creativity, why not look for it, see how it is being done, and show your people it can be done. Most people won’t change until they see value in the change. Find and celebrate the positive deviants.

    This is hard work, our society can’t concentrate for more than 15 minutes and we are all guilty when we buy into sound bites and staggeringly simplistic solutions.

    Sorry, venting…

  38. It seems to me that there’s an assumption from Miles that his team doesn’t want to reduce bugs throughout the process. Has he verified that they don’t?

    His team probably knows best. I would suggest to Miles that he ask his team if there is value in assessing the bug situation throughout the process. If they determine that there is, then the follow-up question should be “how do I help you do that?” I agree with Phil Downs in that it may not be a simple solution.

    I don’t think a carrot is necessary, provided there’s no stick for taking the time to do things carefully (and possibly taking longer) along the way.

    Andrew

  39. David Lair says:

    I weight in with Clarke Ching.
    This is not a motivation issue. It is more important that the design, planning, communications, and early validation occurs than the software code. Done right the code will happen effortlessly. Use the scrum process which requires constant communcations across small teams. I will add this secret: The cheapest bang for the buck in software development, bar none, is constant inspection and review; early and often, and, not in big meaningless meetings. In the 1980′s, Michael Fagan, who is credited with being the inventor of formal software inspections, developed the Fagan Inspection (look it up: wikipedia). It is a little effort but the payoff is huge. The motivation comes from doing something right with very little errors.

  40. Chris Cardew says:

    1. Make the specification of the product clear in detail up front
    2. Limit changes to specification to a minimum
    3. Ensure that in the detailed schedule there are no software tasks of more than two weeks in length.
    4. Instill a culture of good practice with all software being peer reviewed with standard commenting. Preferably not an ad hoc software quality process
    5. Try to test ‘integration’ of software modules with hardware as early as possible
    6. Don’t accept from marketing that a schedule can be halved if you double the number of software engineers.
    7. As you mention Dan, bonuses do not motivate…in fact they have the opposite affect. Agree salaries up front as you would for any post you offer. Then make life as enjoyable as possible for the software engineers; free soft drinks in the fridge, fresh fruit, choc bars whatever. People HATE working weekends even if there is a bonus waiting
    8. Communicate properly and regularly at all levels; engineer, management, customers, directors to ensure that you don’t get hit by a something that you could have predicted coming. e.g. unexpected behaviour of hardware; feature creep, memory limits

  41. Ian Tang says:

    My answer: Design, Software Architecture & Standards

    Beleive it or not, lots of developers has the same Intrinsic Motivation to do what you wanted (Minimize Bugs).

    BUT bugs pop-up in unexpected places, such as:
    - People don’t use the software as per design, if you want less bugs … limit your interface/client-side
    - When combining a massive codes from several developers/teams, the code will not … that’s architecture & set code structure standards

    Like building a skyscraper, a lot of it is Design, Architecture & Standards.
    ————-
    Developer is task to make functions work, not the unanticipate stuff parts (where the bugs lie)

  42. I would meet with them ask them, “Do you think there could any advantages to de-bugging our software as we go along instead of at the end?” (Maybe that’s obvious – I don’t know – but there are offsetting disadvantages) If they say no, then ask, “What about (mention whatever you see)?” Open it up for disadvantages, divided into what would work or not work about it for them, for the company, for the consumer. Then ask, “What could we create that would be new and exciting – and advantageous for you? For me? For the company? For the consumer?”

    Then get to work or fire them all.

    Marty (get a group of kids together … they’ll come up with something)

  43. Heather says:

    Ask the developers themselves the pros/cons of debugging along the way versus debugging at the end. Get their point of view and involve them in the process.

    Does Miles believe debugging during the process saves time, therefore saves money…or has something ‘happened’ that he now believes debugging should happen along the way?

    What is HIS motivation to motivate his developers?

  44. Jim McCarthy says:

    There are two things about the nature of bugs in software that are essential to know.

    1. Team = Product. All the virtues and vices of the team end up in the product and vice versa.
    Product defects are the natural expressions of team defects. Team bugs include process imperfections,
    communications breakdowns, low quality meetings, lack of vision and focus, passive aggression and all
    the myriad ailments human collaborations are subject to. To minimize product defects most efficiently
    you must constantly and effectively address these other defects.

    2. Quality in is more important than defects out. All human made things have defects. For a variety of
    reasons, the inevitability of defects is more vivid in the software world than in many other disciplines.
    However, in all products, including software, it is the ratio of good qualities to bad qualities
    that is the important thing. In general, it is much simpler and cost effective to put goodness in
    than to wring every last bit of badness out. And it should be noted that the way to increase goodness
    is to increase the goodness of all aspects of team life and work as described above.

    One more thought. Long experience has taught me that “the bug count” on a software project is more
    or less a constant over time. What changes is our effort and focus on bewly finding extant bugs. As we fix
    the bugs we find, we inject new ones at a more or less constant rate. The new ones we may not find, or
    they may be more acceptable than the old ones. In any case, what determines a given team’s bug’s rate
    is the team’s endemic defectiveness as an organization. Thus, we must trun, once again, to number one, above,
    for relief.

  45. Jim McCarthy says:

    Sigh. I bring my own bugs with me. Typos in my above post: “bewly” = “newly”, and “trun” = “turn”. Also, some kind of paragraph formatting bug got me. If someone can edit, please do so.

  46. Heidi Kraft says:

    Set the big picture vision and have team collectively determine why this project is so important – to connect to the meaning/purpose. Then get out of their way and so they can have autonomy to explore in their own way. I’m imagining some suggestions on ways to create a space for creativity and problem solving. Thanks for doing this Dan – fun to problem solve with a group.

  47. Maura says:

    Greetings – I love questions like this. I’ll tell two short stories to illustrate how starting out with a team of equals, but with different levels or types of skill can work together with high-level results.

    I’d like to say “bugs” are anything worth improving.

    1. Students in a class of different levels of knowledge needed to all be engaged with their strengths for a certification exam. So as teacher I designed a case study role-play where the strongest students were a “committee” the less knowledgeable had to present to in front of the class – and the opener was that “it’s important to say you don’t know when that’s true – and ask for help”. The strong students had a blast inventing questions and framing them positively – the weaker students knew they could ask for a life-line. So the level dignity was equal – they didn’t know they were selected by strengths, they thought it was ramdom teams. Both sets of students reinforced positive feelings, had fun and the learning on these days jumped dramatically.

    2. A group of CPA’s were to put on a business development event. Some of the CPA’s were very detail oriented, some were big picture rainmaker types. We divided the tasks to put on the event in terms of Front Stage, Back Stage, Post Stage. The front stage were the ones who liked public speaking or greating the public, the back stage liked the behind the scenes activities that went into the event, and the post-stagers were the most detail oriented, and were most able to “see” details the others would miss – and their job was feedback throughout and at the end. In a sense they were charged just with “debugging” by noticing what worked, what didn’t and what could be improved. The front stagers were to express gratitude to the entire team in a way to avoid lime-light intoxication at the event.

    I am not familiar with software developers – but I would assume the principles of positive self-selection, equal dignity of all necessary talent sets, playfulness, and each person playing the proper position will naturally create the positive peer pressure to enhace the results of software development and improvement. The examples above are just provided to stimulate possible ideas.

    All the best!

  48. Durga says:

    Two teams of developers, one that codes, one the bug fixes. Put your senior people (whom I assume are your best) on the bug fix team. The bug fix team pulls early coding projects from the buggiest tested and they learn where most of the problems are coming from and how long they will take to correct. Bug fix team assigns projects to group after an iteration or two of this.

  49. patrick says:

    setup a process where, in each phase of the development progress (task completed or once weekly, whichever comes first), a peer reviews the code of the developer responsible for it.

    the developers will be intrinsically motivated to produce better code and will necessarily unit test their own work.

    with this method, you don’t even need to set standards that are measured — the programmers will inherently do a better job and the collaboration aspect will prevent them from feeling like they’re being micromanaged.

  50. Avnet’s CEO Roy Vallee answered this well in a recent interview:

    “Any time you want a group of people — whether it’s all employees, a specific segment, a management team — to buy into a new concept or an action item, if you give them the opportunity to participate in development of the item itself, or what action is going to be taken, then you have a lot of buy-in going forward. Any time the ideas are cultivated in a dark room, especially in the corporate office so to speak, and then you try to sell, it’s going to take longer to get implementation.” (full interview here: http://knowledge.wpcarey.asu.edu/article.cfm?articleid=1836)

    This reiterates what many commenters have already said: let the people be part of the solution.

  51. Trevor says:

    Crowd source the solution from them just as you have done with us. I suspect that developers are problem solvers and when presented with the problem and some broad parameters and autonomy to solve it, great things will happen.

  52. Cheryl Bruemmer says:

    I would certainly advise against any type of incentive. This can create competition among team members if there is any attempt to single someone out and “reward” them. It will also focus their attention in the wrong direction. My question for Miles is why does he think he needs to motivate them? I realize this question may sound like a simplistic or even flippant question but it is not. It is the fundemental question.

    TO give full disclosure. I know nothing about code or developing. The question I have is WHY are the bugs built in. Is there something built into the management system of the business that causes them to aim for completion of the project without as much consideration for “bugs” in the code? If so, this is a management issue not a developer issue. Is the timeline for completion realistic? Are they clear that “no bugs” is in their job description and not just a part of QA? There are many questions to ask here to uncover the root cause. People generally behave logically based on the system they are provided.

    The question of why the bugs are being built must be asked and if the developers are given an opportunity to discuss it without fear of repurcussions you may find the answers surprising. Once the answers are known then a solution can be found. I agree with many of the above comments that the developers must be a part of the conversation to create the solution. Who else could be?

    Incentives and rewards will not work. They will cause a different type of problem and they will not cure the current one.

  53. brysmi says:

    To bang on the agile drum just a little more: Forrester Research has a good current summary of the state of Agile QA:

    http://www.forrester.com/rb/Research/few_good_agile_testers/q/id/55596/t/2

    I also like to discuss things up front in terms of the “iron triangle” of software quality — Scope, Schedule, and Resources. Pick two and recognize the third will be compromised, and make sure all stakeholders (including development) are on the same page about these decisions. Of course, finding bugs early is a way to mitigate expense and time if you are putting less emphasis on schedule or resources.

  54. Jorge Fusaro says:

    I assume the bugs exist because people are doing the coding. Eliminating human error is a tough pursuit. Here are some quick ideas that could help motivate the reduction of bugs.

    1) Let coders come up with the incentives (motivators) to do their jobs better. Then link that motivator to their job.
    2) Offer flex time, let developers code when they are at their best (which could be 3am).
    3) Delineate the development process starting at the end.
    4) Spend more time in the hiring process to identify people who LOVE to code and have a high inclination towards excellence.
    5) Open up the conversation to discuss why it’s worth avoiding the bugs and doing it right the first time , rather than coming back to fix it.

    PS: Hey Dan, just bought your latest book while buying gifts for “others.” This one is for me! :) Happy Holidays!

  55. Roy says:

    Perhaps the following approach would work:
    1. Before the project begins, the project manager invites the programmers in and hosts a discussion on the pros and cons of debugging as you go vs debugging at the end of production. I would also suggest that an end user be in the room to explain his/her experiences/frustrations with dealing with a program that hasn’t been adequately debugged.
    2. Briefly instruct and inform the programmers on the differences between “discussion” and “dialogue”. Discussion brings all possibilities to the table without fear of judgment or ridicule. Dialogue is the process of talking through each option and finding the best one.
    3. I would suggest that daily or weekly Discussion/Dialogue sessions would be beneficial at first. After the initial session, they probably won’t take long because they can become item/problem specific.
    The simple process above allows the programmers to identify the problems and work through them as they go. Perhaps they will find that debugging as you go AND debugging at the end are necessary to the process.

  56. Roy says:

    One more thought: it would seem to me that debugging as you create would provide more learning opportunities for the programmers. I would suspect that the more serious programmers love to learn from their mistakes or from the unexpected surprises that pop up. Perhaps turning the debugging process into a process of inquiry and learning would help them be more proactive in their approach to development of a product.

  57. Bob Faw says:

    In addition to finding the most effective system (non-waterfall) I use techniques similar to Heidi Kraft #47.
    1) Brainstorm with the whole team a vision of how they would love the project to look at the end (including Q&A/debugging).
    2) Prioritize the vision ideas so there are 5-7 top components of that vision.
    3) Ask them to describe vividly how this would look and feel to achieve this. (This creates appealing internal imagery that guides fact-driven and emotion-driven decision-making.)
    4) Imagine the coding process is completely open to redesign. Brainstorm how to handle quality issues (connectivity, bugs, etc.) in an ideal way to ensure the desired outcome.
    5) Choose the ideas that make the most sense to the group. Highlight the interesting and new ideas.
    6) As a leader give frequent (particularly at the beginning) reinforcing feedback when you see the new great ideas being applied.
    7) When unexpected mistakes happen, bring them as challenges to solve to the team.
    8) Keep sharing new learnings between members along the way.

    This process tends to support high motivation and easier innovation. Making problems into group challenges tends to increase collaboration and much faster learning.
    Best wishes!
    6) Decide how to implement

  58. jan zlotnick says:

    “HOW would you MOTIVATE a software team to REDUCE BUGS in a product THROUGHOUT the development PROCESS instead of just the end?”

    Miles is asking for an algorithm.
    Background: software people are into the trees of a process. We need to show them the forrest. “Show” is helping them use the right side of their brains, see new patters, make new connections. Visualizing is key here. (see NYT interview with Daniel Schwartz, ceo Timberland http://bit.ly/8Ozo1j )
    Steps to helping software teams see both their process and the big picture, which will then enhance their right brain to work with their left brain and result in reducing bugs during process development.
    1. Place two large white boards in both the “working room” and “eating/conversation” room (kitchen or lounge).
    2. On one giant white board A, show a stunning, imaginative, dominant illustration of the finished product by a skilled artist.
    2b. On same white board A, show series of subordinate illustrations, in black and white, showing various architectural, blueprint-like perspectives of product.
    3. On different white board B, placed to left of board A, have the team come up with and name this board based on a fun, game-like “team name” based on their particular team’s function in the process. Example, if the product was a new Nike basketball shoe and my team was involved in the bottom outer tread, we might name our team “The Burn Blasters.”
    3b. Under their fun, competitive team name is the line consistent with all teams’ boards: “Zero Bug Tolerance”
    3c. Under ZBT line, are 3-5 bullet points that the team determines for HOW they in their particular part of the overall process CAN IDENTIFY and DE-BUG THE BUGS.
    3d. A small, separate red box titled “BUG BOX” is where team keeps count of the bugs they’ve identified and de-bugged (e.g. 10 / 8 shows they’ve i.d.’d 10 bugs and de-bugged 8 of them. Thereby, establishing the reality of bugs that will just have to be addressed at end (remember, the goal was to reduce, not eliminate” — even though the “zero tolerance” aspiration is to motivate.
    3e Under bullet points, there’s plenty of working white space for team.
    (NOTE: THESE BOARDS ARE WIRELESSLY CONNECTED TO A PRINTER FOR SAVING AND PRINTING OUT IMAGES, SO TEAM CAN DOCUMENT AND ERASE)
    3f. At very bottom of board, on a colorful banner, is the teams’ own voted-on destination for where they would like to go, anywhere in the world, as a reward for being the team to do the best “bug-id and debugging” (e.g. CABO, MEXICO in orange, pink and blue marked text and any little design elements like waves, palm trees, drinks, etc they want to draw in).
    3g. Smaller, but still done with a flair, and under the destination desired by the team if they win, is their voted-on hotel-spa and/or restaurant within 100 miles that they would win time at for coming in 2nd.
    3h. Each “bug” identified earns a team (and so motivates them to simply i.d. as many bugs as they can) $200 per bug or whatever is reasonable but motivational for a team to collect and split and significant sum, especially should this be the only prize they win, a likely scenario the larger the number of teams. A bonus of $100 per de-bugged bug is awarded.
    4. At end of process, when all teams come together, the winning and 2nd place team may confer to award a 3rd MVP (most valuable players) team and that 3rd place team wins an additional $$$ prize to be split among them.
    5. T-shirts and hats and light or heavy motorcycle jackets, depending on weather and team choice) are given to each team member, as well as temporary tattoos: the team name/logo and t-shirt/hat/jacket/tattoo are designed and implemented by top, name designers brought into the company to meet with teams to get their own particular vibe and personality and input.
    The master company logo is complementary yet can be subtle and subordinate to the team name/logo, per the team-designer discretion
    6. The winning teams photos and/or videos are put onto a separate website and internal social networking site (e.g. Tumblr).
    7. Each quarter, the teams participate in some kind of other, totally work-unrelated competition (e.g. bowling, softball, Top Chef, music/bands, etc) they vote on together.
    8. End of Year/Holiday: prizes to top 3 teams and individuals from all/any teams for pre-determined achievements ranging from technical to social and comical (e.g. Best Dressed, Worst Jokes, Most Likely to Go AWOL)

    Miles asked for motivation. You can’t shortcut the process of motivation any more than the process of their technical endeavor…and expect success. It’s got to be remarkably conceived and executed. It will matter.

    - Jan Zlotnick

  59. Dear Miles, you ask the impossible.

    The larger the product, the greater the frequency and complexity of the bugs. The occurrence of bugs in software is like gravity: there’s no sense in trying to eliminate gravity, you have to learn to live with it. And the way to live with the inevitability of bugs is to build less and test more frequently.

    There are two ways to accomplish building less and testing more frequently.

    1. Reduce the number of features to the essential minimum, develop, build, test, debug, release, maintain (gather user reactions, design new features, develop, rinse, and repeat).

    2. Divide your project into units, and test the units, also known as, unit testing (everyone has heard of it, no one does it). The earlier unit testing is introduced into a project, the sooner bugs can be identified and destroyed.

    Building less and testing more frequently won’t produce motivation, but it will help your developers to maintain their motivation by

    1. Helping to reduce the duration of the development life cycle. Nothing kills motivation like three months of work on the same project, except perhaps for being buried beneath the landslide of bugs that will ensue at the end of such a marathon.

    2. Creating an opportunity for competition and/or collaboration within the development team. Breaking a project into units smaller than FRONT-END and BACK-END will require the following: more design (never a bad thing), and more communication (sometimes a bad thing, unless someone capable is in charge of the meetings).

    The holy grail of building less and testing more frequently is to get real. If you’ve never read it, the 37signals publication Getting Real is not to be ignored. Getting Real plays to the build less, release more often approach to mitigating the severity and frequency of bugs.

    The next best approach, playing to unit-based development, is test-driven development – something else I’ve never encountered in the wild. Start with a functional spec – what does this program do? Then write some code that pretends the functional spec has been implemented (unit testing frameworks make this possible). When you run the test code, it should fail on every single count. Next, implement the functional spec. The development cycle is complete when the test code executes without error.

    Once you’ve decided upon a mode of operation – a choice that will likely be dependent upon your team’s skills – then you must match individual talent to project role. Nothing breeds motivation like a passion for one’s work.

    Good luck!

  60. Mark says:

    As a developer, I don’t introduce bugs into the code because I am lazy, or because I don’t see the value in fixing bugs early instead of later (1:10:100 rule; for those non-development types :) is the ‘cost’ to fix a bug in Development, Test and after Release).

    For me, I think the main reason bugs usually get introduced is either (a) unclear requirements and I make an assumption, (b) I haven’t thought of all the possibilities of a section of logic in a program, or (c) carelessness/I missed something (I’d like to think this doesn’t happen, but sadly, I still have my ‘D’oh’ moments).

    I think for your team, the development team (developers, requirement gatherers, testers) need to meet (perhaps without the glaring eyes of management) to discuss why bugs slip into your organizations code. For arguments sake, I’ll assume the problems are the same as mentioned above.

    After identifying why you have bugs, the next step is how to fix it. For the reason I have bugs, I think the biggest potential solution would be to introduce pair programming (as previously by other readers as well). [Pair programming is when 2 people sit side by side infront of one keyboard working on the same problem-- writing code for a portion of the application]. Pairing between developers is good, but so would be pairing with a developer and a business requirements person (whichever term you use for the person that understands why the program should work in a certain way).

    The catch with pair programming is the perception that you’ll get only 1/2 the work done (2 developers working on something instead of one). While I don’t fully by thats the case, I do appreciate the perception.

    Now, the question is not just if you have asked your team to make the commitment to bug free code, but is the organization on the same page. There will [probably] be a cost, but lets just for argument sake assume the organization is on the same.

    Introducing pair programming (and potentially its additional cost), should help to eliminate at least some of the issues listed above (a) requirement misunderstanding, (b) additional possiblibles, (c) carelessness.

    It would also show the team that you understand that the reason their are bugs isn’t that the developers are not good developers. They could be excellent developers and there would still be bugs. Just that the team is stronger when it works together (ouch, that sounds very cliché, but its true), and the organization is there to support the team.

    And as a developer, kick-ass machines never hurt too…
    …and at least 2 monitors. :)
    [Totally agree with you their Scott Smith!]

  61. Mark says:

    I should have mentioned, that while I agree Agile would be great to use, if the organization is a pure Waterfall shop, it might be unrealistic to expect that the team is going to start producing better code right off the bat with the new process. It might be better to try baby steps.

    I know thats heresy, but depending on Miles’ timelines, if he is looking for results in the short term, switching fully to a brand new development process across the board might do more harm then good.

  62. Mike Visagie says:

    Unless Miles can ‘un-limit’ beliefs, he can develop his people’s skills all he likes, but they will be hard pressed to actually use them under pressure, and with any degree of sustainability.

    Apart from identifying what it is that limits people, we should also recognise how critical it is that we discover what their real talents and passions are. If we can un-limit their currently limiting beliefs, and stir life into their passions and talents, then we create an environment in which they are inspired to, literally, unleash themselves for personal and organisational success.

    These kinds of questions Miles could ask his team, as a means of catalyzing change in thinking and behaviour are:

    • What inspires me?
    • What am I passionate about?
    • What is my purpose and personal vision?
    • How do I make the shift from being so powerfully driven by habit, to operating from a place of awareness, self direction and choice?

    To engage the whole person in a work context Miles needs to focus on creating the space for individuals to find the ‘True You’ or ‘meaning to my life’ connection. Their work and leadership role then becomes a vehicle through which they are able to live what is important to them. In return the business will get the potential and energy that flows from engaging an individual’s physical, mental, emotional and spiritual quotients.

    This aspect of engagement has less emphasis on the ‘doing’ of work and leadership and more emphasis on the ‘being’; the self awareness and self belief to harness intuition, talents and strengths. This falls into the SQ/EQ domain and is therefore more transformational than transactional in nature.

    What weknows works best is engaging and growing people in a way that makes sense to them, wherever they are at in their lives, leaving them with a renewed sense of hope, possibility and self-belief to engage with and live the change they desire, and which the business needs. No matter what the required business outcome is, if people are able to approach it with strong sense of self and see the same context through new eyes, the possibilities for engagement and the sustainable delivery of strategy and process are so much better.

Leave a Reply