61

I work in a largish, multi-team software development shop that builds a vertical B2B solution suite for a highly regulated domain. We are trying to become more Agile; we are iterating better than we have in the past, but there is still a lot of waterfalling going on.

Over the last year, we have become pretty hardcore in adopting the principle that engineers must fix their own defects (those found internally and those that escape to the end users). Not only are they supposed to correct them, they are supposed to correct them on their own time, without impacting plans.

I get the internal stuff, and in theory I buy all of the accountability arguments of the escaped items too. In practice though I have observed the interruptions to correct the defects is both velocity- and morale-killing and they make predictable project plans darn near impossible to build. Plus unhappy engineers are darn near impossible to keep.

It is not that we have bad engineers who are just generating bugs left and right; it is that we have highly complex systems with mixes of new and legacy technology and significant external, internal, and governmental timeline pressures resulting in an environment that does not result in pristine software. Bugs exist and that's a fact.

I am trying to make peace with this. I feel like I can be more open to our approach, but I also want to minimize the highly costly disruptions the process puts upon the teams and the human costs of the demands of off-hours work. I feel like we are trying to solve a quality problem backwards by fixing bugs instead of focusing on preventing their generation in the first place.

Are there any experienced project managers out there with some words of wisdom to share on this topic?

Barnaby Golden
  • 19,475
  • 3
  • 17
  • 50
Larry Domonico
  • 611
  • 1
  • 5
  • 3
  • 71
    CodeGnome's Law of Transparency says "No invisible work, ever!" Bugs are the responsibility of the business, either because of budget, process, or other leadership failures. Trying to get "free" bug fixing doesn't create engineering buy-in; it's just capitalism run amok. – Todd A. Jacobs Aug 04 '16 at 03:19
  • 15
    I bet you have very long pointless arguments about whether things are bugs, when it's all just work really. I don't think this could happen on a self organising team, I assume the development team have no say on iteration commitments or on this policy? – Nathan Aug 04 '16 at 07:09
  • 2
    "I feel like we are trying to solve a quality problem backwards by fixing bugs instead of focusing on preventing their generation in the first place" - you will never stop bugs happening in the first place. The best you can aim for is to make sure as many as possible of them are found before it gets in front of the client. – rdans Aug 04 '16 at 08:54
  • 8
    And making an assumption that bugs are always a failure on the part of the developer shows a lack of understanding of software development. It's not like laying bricks – rdans Aug 04 '16 at 09:05
  • 23
    And even if it was like laying bricks, supposing you discover a mislaid brick, you don't find the bricklayer responsible and make them knock (part of) the house down and rebuild it on their own after hours. It might feel satisfying as a punishment for the bricklayer responsible, but it's a stupid way to build a house. – Steve Jessop Aug 04 '16 at 09:10
  • 28
    I presume that your "hardcore" environment encourages locking the testers in the basement for the whole time the programmers are fixing bugs, as obviously they didn't spot the bug before it got to the users. And presumably you financially penalise your customers for not nailing the requirements right down and listing all undesirable system behaviours? Otherwise what you are doing is just nasty and vindictive. You pay someone to work 7 (or 8) hours a day - if you want them to work more than that reward them for it, but don't make it a regular thing or you will find yourself short-staffed. – Spratty Aug 04 '16 at 09:15
  • 9
    How on earth do you determine whether people genuinely are fixing the bugs on their own time, and not just padding it into the next day? Highly granular timesheets? What anti-bug processes do you have in place? What are your local laws regarding mandatory unpaid overtime? – pjc50 Aug 04 '16 at 12:25
  • 3
    Not an answer, but if your company wants to become more agile, it will have to reverse its mindset. Agile works by empowering developers, giving them more control over their work and the project as a whole, but most of all by accepting reality. – Cronax Aug 04 '16 at 12:55
  • 9
    In my environment, it would be illegal. – MCW Aug 04 '16 at 13:00
  • 2
    what country is this in? surely its illegal – Ewan Aug 04 '16 at 15:23
  • 2
    The system produces results (good and bad). Read Deming. Forcing responsibility for quality problems onto individuals will only cause personnel problems for you. Fix the underlying problems with your process and team, and results will follow.

    Meanwhile, it sounds like your management team has a culture issue to work on.

     – John Yetter Aug 04 '16 at 15:46
  • 8
    This has my vote for the ultimate morale torpedo. What's the average length of tenure on your team? – Tim Aug 04 '16 at 17:11
  • 2
    I simply cannot envision any end result that is more favourable after having implemented a system in which developers have to do their job for free on their own time. You only stand to lose with this system, in nearly every conceivable area. You'll lose morale, productivity, and increase turnover. I'd get rid of this as fast as possible. – pay Aug 04 '16 at 17:19
  • 4
    I can't believe this post. How entitled do you have to be to think that demanding free work is ethical? – Rob Grant Aug 04 '16 at 22:57
  • 29
    Does this principle extend to other parts of your organization? For example, if your engineering team can't retain qualified developers, do the engineering manager and HR director work without pay until the management "bug" is fixed? – David Gelhar Aug 05 '16 at 00:56
  • 1
    @CodeGnome Well, there goes your next few DARPA contracts to work on next-gen stealth technology... – corsiKa Aug 05 '16 at 15:36
  • 7
    You wouldn't want me on your project because I'd be darn sure that my code works before submitting it. At least that will be on company time. To heck with the schedule you created. If I don't get paid for fixing bugs then I'll make sure I get paid for all the extra testing prior to submitting the code to make sure I don't have bugs. – Dunk Aug 05 '16 at 16:35
  • 13
    I'd also become a requirements lawyer. If you claim there's a bug, I'll just refer you to the requirements document and say "where does it say it can't work like that?" It doesn't matter how broken the bug really is. If it isn't explicitly documented and you expect me to work on my own time then no thank you. You should have written it in your requirements document. Your requirements document obviously has a bug in it. Go fix the requirements document on your own time. – Dunk Aug 05 '16 at 16:38
  • 2
    @CodeGnome No, in capitalism (done right), you're paid for the services you provide. It's just crooked business practices run amok. I'd use the word "theft," personally. The same crap happens in any economic system. – jpmc26 Aug 06 '16 at 01:17
  • 5
    Where I live (USA), a local company that had this practice was challenged in court. The company's programmers received significant payout since "salaried employee" does not mean "management", and overtime laws do not exclude salaried employees. – pojo-guy Aug 06 '16 at 04:38
  • 1
    Upvoted this terrible, terrible question that nobody should ever be asking. I would just laugh, and walk out at 5pm, and tell them unless they start scheduling time for bugfixing, they're getting no fixes. But I have the advantage that I am in an environment where the jobs are easy to come by, and can leave with zero notice. Trapping employees in such a state is truly evil. – Dewi Morgan Aug 06 '16 at 16:40
  • 2
    By asking this question you've demonstrated that you don't understand the elementary basics of the nature of software. You may be in the wrong business. – Jeremy Anderson Aug 06 '16 at 22:23
  • 1
    One of the first things I learned about in PM training years ago was 'Cost of Quality'. It sounds like your firm has tried to pretend that there is no cost associated with quality. There is lots of research to say this isn't wise. – CWilson Aug 07 '16 at 02:30
  • "myself and other PMs in my organization do budget time for "unexpected" things such a scope creep, missed requirements, misestimation, but it's frowned upon to budget for bugs" Who is accountable for scope control, requirements compilation and estimations? Why are developers held accountable for honest mistakes they make, but the other role players in the organisation are not? –  Aug 04 '16 at 09:56
  • This is not an answer. This is a comment to the first comment (by Larry Domonico) of the question. Judith, please use a comment instead answer next time. – Sergey Kudryavtsev Aug 05 '16 at 08:56
  • I agree with @SergeyKudryavtsev. Please add something actionable or productive to your answer to avoid having it flagged as "not an answer." – Todd A. Jacobs Aug 05 '16 at 16:37
  • I don't believe Judith had the rep to comment before this answer gathered a couple up votes. – gtwebb Aug 05 '16 at 22:55
  • 2
    Excellent idea! I've always wanted to work somewhere with formal methods. It would be great to not release any code until it is proved to be correct. There's no way I'd release before then if I had to fix bugs off the clock, so we will have an executable specification and formally verify our work to that spec. – dave Aug 08 '16 at 00:32
  • Has anyone considered the legal implications of forcing a worker who is paid hourly to work on his own time? It could be an interesting lawsuit. – Dale Wilson Aug 08 '16 at 16:03
  • After working 45 hours a week for a year just because I didn't know what else to do with my lunch break, I got called into the boss' office and told that I needed to work more, for no extra pay of course. So I said "yes sir" and immediately found a new job. If your employees respect themselves, they will do the same thing. – Devsman Aug 08 '16 at 16:17
  • 2
    Out of curiosity, have you heard of unit tests / TDD? You might want to look into making your team more test-driven. It is a law of nature that engineers are going to build products with a lower quality standard whenever there is an impending timeline forcing them to rush. Pay them to write the tests up front, and you will catch most of the bugs before they hit your users. Most bugs aren't the fault of the programmer. They're the fault of management trying to rush a thing into production before it is ready. – Theo Bendixson Aug 08 '16 at 18:43
  • 1
    ...engineers must fix their own defects... I generally agree with that principle, but the implementation isn't sustainable. What happens when the dev team resigns? (I was on a team that essentially threatened similar to CEO.) You posted because you see the eventual consequence. Are you looking for a way to maintain the status quo indefinitely? Are you thinking that there are novel ways of making it acceptable (indefinitely)? Or are you looking for guidance on how get process changes implemented by convincing the business managers? – user2338816 Aug 09 '16 at 07:17
  • OP must be trolling... – Nahum Aug 11 '16 at 04:35
  • Do you have an SQA plan and a scope management plan? – gatorback Aug 11 '16 at 14:53
  • The OP did not ask the question in the title; the original generic title of this question was edited. I suggest reading his comment on my answer to get a better feel for the original intent of the question before commenting or answering. – Vicki Laidler Aug 11 '16 at 17:44
  • 1
    Let's presume you have two developers. A) a rockstar and B) a poor performer. The rockstar has one bug per 100 lines of code. The poor performer has 5 bugs per 100 lines of code. So, let's assume the rockstar puts out 1000 lines of code a week and the poor performer puts out 100. The rockstar would have 10 bugs per week while the poor performer would have 5. Let's just say, it doesn't take long for the rock star to learn it's better to simply do less work – Scott Stevens Aug 27 '16 at 04:10
  • This sounds like a company that is ripping of their developers – WJA Mar 28 '19 at 13:54
  • I came across this story and it is sad to see it happen everywhere. Check my similar story here https://workplace.stackexchange.com/questions/136342/how-can-i-argue-against-the-idea-of-working-overtime-to-fix-bugs-constantly – Qiulang 邱朗 Jul 16 '19 at 04:45

19 Answers19

79

And not only are they suppose to correct them, they are suppose to correct them on their own time without impacting plans.

This is your problem. Why don't your plans include the time for fixing bugs that you know will be there?

We all know it's impossible to write perfect code. We all know that bugs inevitably creep in. Expecting engineers to fix their own bugs on their own time without planning for that work is not "hardcore": it's bad project management. It means the work required to fix the bugs is hidden work, invisible to upper management & other stakeholders.

There are a variety of ways to plan for that work, & there are a number of other questions here that discuss that. But you have to get it in the plan, and stop expecting your engineers to be perfect.

Which is not to say that you shouldn't also continue to work on bug prevention, of course. But your approach as a PM and as a team needs to accommodate the fact that bugs exist.

If I were going to put forward an argument against this practice, I think I'd do it with a risk management approach. Identify bugs as a known risk, and list a variety of mitigations, including all your bug reduction practices as well as planning for bugs that escape nevertheless. Maybe add poor morale and/or exhausted engineers as another known risk, and suggest as a mitigation ending or limiting the practice of having employees fix bugs on their own time. Point to some studies on the effects of overtime on employee performance.

If you need to have something else to put in that accountability slot -- which presently seems to be more punitive and individually-oriented than is generally encouraged in agile development, which emphasizes the team and the team's investment in a quality product -- hm, I don't know. Maybe focus on accountability for violating the bug-reduction practices, instead of on bug escapes which are a fact of life.

Vicki Laidler
  • 3,640
  • 11
  • 17
  • 5
    Very good points and myself and other PMs in my organization do budget time for "unexpected" things such a scope creep, missed requirements, mis estimation, but it's frowned upon to budget for bugs. That's the accountability piece - we enforce accountability by making them pay from thier own time. I don't love it. I don't like it. I am just trying to either make peace with it or construct a concise cogent argument against it. Hence my post here. :) – Larry Domonico Aug 04 '16 at 01:21
  • 36
    I see. If your org is committed to agile, "no invisible work" is a pretty core principle to put forward against the "frowned upon to budget for bugs", esp if the org position is "bugs are a fact of life." An org culture that a) accepts that bugs are a fact of life, and b) expects employees to deal with them on their own time? Good luck keeping engineers happy.. or keeping them at all! – Vicki Laidler Aug 04 '16 at 02:02
  • 48
    My expectation is that if developers are asked to pay for bugs out of their own time instead of out of company time, then they will be over-cautious about releasing code, spend excessive time testing it or pegging out detailed low-level specifications designed to ensure that problems "don't count" as defects since the code is to spec, and then when defects are reported will be strongly incentivised (a) to conceal them and/or shift responsibility elsewhere; (b) half-ass the fix. You're asking your own engineers to be more like those crappy corporate suppliers you hate dealing with. That's risk. – Steve Jessop Aug 04 '16 at 09:14
  • 15
    @LarryDomonico: if you don't budget for bugs and they do occur, you have a clear bug in your budget. You have to rewrite the budget in your own time now. – RemcoGerlich Aug 05 '16 at 07:58
54

Just as a side note to the other good answers - developers tend to have minds that look at process and (un)consciously find ways to game it.

What you are training your developers to do here is to not raise tickets for defects they find when they are developing (as either they, or possibly worse for them, one of their colleagues) would then have to work late to fix it.

If it's a subtle bug, they may just hope nobody notices (particularly if it's not directly related to what they are doing at that point in time).

It's well known that the earlier you find a bug, the cheaper it is to fix - if this results in more bugs being found in live rather than during development cycles, then this can't be a good thing.

Paddy
  • 641
  • 4
  • 4
  • 8
    +1 for calling out the actual effect that such a policy is likely to have, when applied to the very personality type that predisposes a person to a career in software development. – Dan Henderson Aug 04 '16 at 20:33
  • 10
    My father saw this exact problem in (emerging market) factories decades ago where the workers were docked pay for making mistakes. The result was that mistakes would be hidden and not be found until the cost to correct them was much higher. This policy was causing really big problems and doing little to prevent mistakes. – JimmyJames Aug 04 '16 at 20:56
  • 1
    Another possibility is padding other estimates to include bug fixes so they don't have to work off hours. – jpmc26 Aug 06 '16 at 01:26
  • 4
    @jpmc26 I wouldn't call that padding, rather just good estimating. There will always be bugs to fix in any iteration. – Paddy Aug 06 '16 at 09:13
  • @Paddy I mean straight up lying about how long a particular task will take, over-estimating it so it's enough time for feature + bug. If they were being honest, they'd give a lower estimate for the actual feature and then have separate time for the bug. I can't say I'd really blame someone in this situation, but wouldn't be exactly honest. – jpmc26 Aug 06 '16 at 15:57
48

Over the last year we've become pretty hardcore in adopting the principal that an engineers must fix their own defects (those found internally and those that escape to the end users). Not only are they supposed to correct them, they are supposed to correct them on their own time without impacting plans.

Let me ask you a question. Whenever a plan changes, do you change the plan on your own time?

Nobody is a robot. Normal humans make mistakes. And the more valuable the work of someone is, the more time it will take to fix a bug in it. I work on core components that save the company tons of time. However, if there happens to be a bug, then lots of components are affected and it will take a lot of time to properly fix it. The second you let me fix a bug in that on my own time, you will get a letter from my lawyer. You want me to work, you better pay for it. You want me to do regular overtime? You better have a reason. "Normal business" is no such reason. Most likely it will take a few weeks to hand in my resignation for even trying to pull such a stupid stunt on me.

As a new developer, I would never start at your company. If I am inexperienced, I will make mistakes. That's why you pay me less than others. However, I will be punished for the same reason you already pay me less again when I have to fix it. Why would I work for you then?

People having to fix their own bugs is a good thing. How about asking how that bug slipped through your testing? You do have testing, right?

In my opinion, the error lies squarely with your planning. You are planning people to work 100% and then you need to fix a bug. As if a bug is something you could never have imagined to happen. Bugs are part of developing and improving software. If you want to fix them on time, only plan tasks for your people for 70%. Or 60%. Or 90%. Whatever works for your number of defects. But it's your job to get that right. Assuming there will be no bugs and then letting the developers pay for your failure to come up with a plan that matches reality is going to get you a very empty development department really soon.

If you want to have fewer bugs, you will need to educate your developers on techniques to prevent them. You will need to give them the time to actually use those techniques. And you can do metrics on the bug tickets. But be careful with that. I have rarely seen a developer rushing a feature to production because he or she was keen on delivering a buggy product. The most likely reason is a project manager breathing down the developers neck because he or she stupidly promised that feature to the customer without consulting the developer for a realistic timeline. So when you have metrics, make sure you include all factors. And don't be surprised when the decisive factor is outside the development department.

To sum it up: making your plans work including bugs is the project managers job. If the bugs conflict with your plan, it was a faulty plan. If the plan only works if things work perfectly, the world would not need project managers. I could do that with a two-line script. So train your project managers to work with reality and train your developers to make reality more predictable.

nvoigt
  • 8,475
  • 19
  • 34
  • 2
    Created an account here just to reiterate, "The most likely reason is a project manager breathing down the developers neck because he or she stupidly promised that feature to the customer without consulting the developer for a realistic timeline." This happens all the time where I work. – Chuck Aug 10 '16 at 13:56
29

This is a troubling post. Your company is penalizing its workers for what is a normal and expected occurrence--performance variability. The whole reason to "punish" someone is for a behavior change, to replace a maladaptive behavior with an adaptive one. In this case your punishment will yield nothing because we do not have the capacity of reducing variability. In fact, neither do machines. Machines also produce variable results and, now and again, will produce a result out of tolerances. Would you make the machines fix such a result on "its own time"? That's not even possible.

EDIT: Much of performance variability are random, i.e., you cannot control them. If you measure the results of a process, it is assumed that observations between +3 and -3 sigma are random results. However, those results could fall out of tolerances and thus be deemed a defect. Punishment to try to control them is EXACTLY like punishing you for rolling a 3 or a 6 on a fair dice toss, with the expectation that 3 and 6 will occur less after a few punishing electric shocks. If you are looking for an argument to change this policy, this is it. Many defects occur because of random drivers over which NO ONE has control. To try to hold an engineer accountable for them is chasing stochastic noise, a futile endeavor.

You are not scheduling time for rework and quality fixes? I don't even know how to respond to that. I guess this: start doing it.

Your developers are most likely exempt employees. However, if you adopted this across the board with other job roles, some of which are non exempt, then you would have a HUGE labor violation on your hands as there is no such thing as unpaid work for a non exempt role. And the reason is because companies make really bad employment decisions such as having its workers fix their errors on their time.

Don't try to get good with your company's policy here. Change it. It's simply wrong under every conceivable standard.

David Espina
  • 37,143
  • 4
  • 34
  • 91
  • 9
    Thank you. You have all supplied me with the information and courage to change something that was very aggressively implemented in the name of quality and customer satisfaction. Again? Thanks for your time. – Larry Domonico Aug 04 '16 at 13:00
  • 2
    Good luck and I hope you are successful! – David Espina Aug 04 '16 at 13:09
18

Aside from the main issue you are asking about, there's also something a little concerning about this part: "defects (those found internally and those that escape to the end users)" I don't see anything about QA being asked to create the missing tests on their own time. This (assuming this is correct) along with your main concern demonstrates to me that the project management group in general is antagonistic towards the developers. I've seen this a lot and it never ends well. I think usually it's rooted in the PMs not understanding how hard it is to precisely predict how long things are going to take in development. That's what I hear when PMs start talking about 'accountability'.

That aside, the policy you refer to is extremely wrong-headed. The other answers give good reasons, bad morale, mental exhaustion, attrition but it's also very self-defeating at a very basic level.

Any seasoned developer has some idea of the following curves in their head:

enter image description here

The key here is that if I am rushing stuff out, I will spend more time fixing stuff than I did writing it. If I spend a little more time on the dev phase, I can get that under control. But there's a diminishing return on spending more and more time on initial dev. Most of the bugs are easy to find but the really tricky ones could take ages to spot, if you spot them at all. QA time has a similar curve to the fix time.

What you care about as a PM is the total cost (purple.) That curve comes down initially as the developer takes more care but starts to go up again. You want to encourage developers to be careful enough to get close to the bottom of that dip but you don't want them to be more careful than that.

The policy you describe is going to push them towards the overly careful end. The reason is if they take lots of extra time to avoid creating bugs (the blue line), that falls under their normal working hours. The fixing cost (red line) comes out of their free time. They can minimize the time they spend off-hours on fixing but as a result that increases the total cost of the product.

JimmyJames
  • 281
  • 2
  • 6
  • 1
    I looked at the diagram for a while but I can not tell what are the axis' on that diagram are supposed to represent. Could you label them, please? – Philipp Aug 04 '16 at 19:13
  • @Philipp I could probably make it more clear but essentially the x-axis is time spent on development. The y-axis is the time for each of the various related activities and or totals. That's why the blue line is straight. I'll make a better version with labelled axes. Thanks for the feedback. – JimmyJames Aug 04 '16 at 20:34
  • I did not understand what the dev time and its cost. Please explain – Krishnan May 04 '18 at 15:24
  • @Krishnan "Dev time" in this graph represents the amount of time a developer initially spends on a given item, like a feature. In this graph I'm excluding time spent fixing defects. Cost is money i.e. QA and development costs money primarily because testers and developers expect to be paid. – JimmyJames May 04 '18 at 16:01
15

The short answer: No, it isn't!

The not-as-short answer:

Your company has come up with the idea that the existence of bugs is a professional failure on the part of the developer. This is not true.

All code contains bugs. Quality code contains fewer bugs.

Your developers are doing quality work for you when they find and fix bugs. This is them doing their job. Would you try insisting your quality control department had to do all their work in their own time if you were in manufacturing?

"Accountability" might mean fixing your own bugs. (Actually, the most important thing is that somebody is fixing the biggest bugs.) Whatever. At your company, it has been twisted to mean your programmers should work for free.

Have any of your devs quit recently? Just asking...

NB: You can obviously see there's a problem with this, so good on you and well done for asking about it. Whoever is propagating this insane philosophy in your company is to blame for tying your hands and your dev team's hands behind your collective backs.

Medlock Perlman
  • 151
  • 4
  • 4
    I can write bug-free code. You do not want to pay me to do it. Let us just say the cost of doing so is something like 99% of my productivity. – Joshua Aug 05 '16 at 18:53
  • @Joshua: write tests; follow development best practice; have fellow coders peer-review your code; get testers to test it; get customer sign-off. Then your code will tend to be better quality code, and tend to have fewer bugs.

    While I do not want to pay you 99x your salary to write bug-free code, I also don't want to pay you your normal salary to write trashy, broken code that's totally full of bugs.

     – Medlock Perlman Mar 16 '17 at 22:24
  • 1
    I'm not talking about typical levels of reducing bugs; they work just fine. Almost all of the cost is when you absolutely have to squash every last bug and be sure of finding them all. When the cost of a bug in production is half a billion dollars you would consider actually paying the cost verify the code is actually bug free (hint: you can't do this after the fact but must start development with this end in mind). Until then, not so much. – Joshua Mar 17 '17 at 01:25
10

"Hardcore" indeed. I don't have much to add to the other good answers, but I'll relate an experience of my own as a developer. I worked for a company in which the culture was similar to what you are describing, in that there was heavy pressure to work long hours and weekends without pay fixing stuff that we'd been required to produce in unreasonably short amounts of time. I can still feel the stress reaction in my body as I write about it.

I think it is fair to say that I was the strongest developer in our small team. I came up with all the original work, setting the patterns which the others then tended to copy. I solved a lot of difficult problems in the challenging application we were developing. I was also the only team member who sometimes said "no" to demands for unpaid overtime - I had parenting responsibilities and a creative life outside of my main development gig. I believe the independence of mind which allowed me to be a creative developer went hand-in-hand with my not being a "yes man". However when time came to appoint a team leader, and my immediate boss put forward my name, his manager said that I "pushed back too much on overtime" and decided to advertise instead. I knew at that point that enough was enough and I quit, soon finding a job that offered 50% higher pay and work-life balance to boot. Feeling well nurtured, remunerated and rested, I produce better work and I feel loyal to my company. I feel invested in the product and I happily work long hours when necessary because I enjoy being part of the team.

Culture matters. A positive, appreciative culture will have flow-on effects in terms of code quality, employee loyalty and retention of talent. Ultimately, when you punish developers for bugs, you are telling them that you don't care about them as people but only as cogs in your imaginary well-oiled machine.

Bugs are normal. They aren't sins. No-one - not Gates, not Wozniack, not Torvald, no-one - writes pure, bug-free code straight up. Software development is an iterative process and the eradication of defects is just one normal part of that process. Honestly, not paying developers for fixing bugs is like not paying gardeners for weeding.

see sharper
  • 201
  • 1
  • 3
7

This practice is good way to drive out your best and brightest, leaving you with a skeleton crew of your bottom performers. I have developed software for generation 4&5 fighter jets and managed software-intensive programs for the USN: PMP Certification, multiple graduate engineering degrees, Eagle scout, yada yada, yada. The original posts leads me to wonder if the issue truly is integrating better SQA practice at the line-level to detect, remove and, most importantly, prevent defects.

Every half-decent engineer will gladly fix a minor 'happy to glad', however, it would not surprise me if the system requirements are not properly documented and any gaps are labeled as defects. Defects in my industry kill people, so engineers take them seriously.

In my experience (and documented across the industry) my ability as the project manager to ruthlessly remove scope creep and reduce function points drives down the number of defects. Reducing scope so that a team of three (or less) good programmers produces higher quality (minimizes software bugs).

Do not attempt to make peace with this practice: you have a serious problem you must address. If left to fester, it (to use a flight analogy) will ultimately reach a flat-spin and end up Class A. Instead, listen to your peers and focus on SQA procedures for defect prevention and you must plan for defect correction (these items should be prioritized into the backlog with customer) in schedules and software process development. Do you have an SQA plan?

gatorback
  • 201
  • 1
  • 5
  • 1
    +1 for prioritizing bugs along side new functionality. In my experience, it makes previously invisible work highly visible. – RubberDuck Aug 06 '16 at 14:32
6

In addition to others, I also find this post disturbing.

I've seen Project Managers want to place all sort of metrics on developers, but never on themselves, Product Managers, QA, management, etc. It takes more than software developers to release a project and get it right.

Do you keep track of what was the root cause of the bug? Who has to work on their own time if it was a missing requirement, or something else that is beyond the scope of the developers control? What sort of processes are you putting in place to make sure that type of bug doesn't happen again, or will get caught earlier in the process?

Bugs are part of the software development process and need to be accounted for as part of time/resource planning. Period. Even more so in an environment with 'highly complex systems with mixes of new and legacy technology and significant external, internal, and governmental timeline pressures'. It definitely sounds like your company is antagonistic towards developers and is trying to make scapegoats out of them.

I've worked on both sides of the fence as both a PM and a developer, and I can tell you that as a developer I would only put up with this 'policy' as long as it took me to update my resume. As a PM I would also be looking for another position where developers are treated with more respect.

Meg
  • 61
  • 1
5

Defects are part of software development cycle. It certainly cannot be blamed on just a single person. The whole chain is responsible.

Any found defect should be categorized and prioritized. Then it should be picked up by the responsible team, quality is a team effort not individual. Afterwards the original developer with the team should do a root-cause analyse to figure out how to prevent something similar of happening in the future. Just blindly fixing them as soon as possible will not improve the process.

Setup a good "zero defect policy" process to prevent just fixing everything instantly:

enter image description here

I would add a fifth classification "Closed" for defects that should never get priority, because they are to trivial. Make sure you communicate clearly and fair.

Niels van Reijmersdal
  • 5,553
  • 20
  • 32
  • Wouldn't a "closed" defect just be a low-priority improvement then? – user253751 Feb 16 '17 at 01:47
  • Often yes, but sometimes I just not worth the time to fix the defect. For example corner-cases that only happen when you do a combination of actions that an actual user would never do. Some test teams are very good in finding such defects, certainly if their target is finding more defects. – Niels van Reijmersdal Feb 16 '17 at 08:51
4

OK, let's skip all the moral and legal arguments by assuming you are working on a cure for the zombie plague and all the developers work 24/7 for their share of the last remaining pure water to meet the approaching (un)deadline.

So you find some bugs in v1 of the cure and look around to assign someone to fix them. You have been bitten too, so you need to get this finished and not upset The Plan as much as anyone else.

Do you choose:

  • Developer A: He missed a semicolon due to tiredness and is the cause of the bug.
  • Developer B: Superfast programmer finished his task early and got a good nights sleep.
  • Developer C: Newly trained developer, super keen, but low experience means high risk of mistakes
  • Developer D: Been here ages and almost fully a zombie and is disliked by the team. No moral penalty, but it takes ages to get things done.

The point is of course that you want to get the quickest/least risky solution to get the job done. Not play some weird morality 'hunger games' with your employees.

Peter Mortensen
  • 155
  • 7
Ewan
  • 926
  • 4
  • 8
3

Try suggesting an alternative approach to the management:

Integrate code quality metrics, and test coverage into the CI server and have developers comply with that.

  1. This checks the problem before it makes to production not after
  2. Makes the developers happy as they are not fixing someone else's problems, they're testing their own code
  3. Provides an objective measure of what's expected from the developers as opposed to "NO BUGS!" which is unattainable
  4. Compliance with standard and test coverage is a better indicator of individual performance than number of bugs, which could be due to the complexity of work assigned and not the person’s skill

If the management aren't interested in going this route, that tells me they’re more interested in getting free work than anything about quality. Having developers write more tests would require allocating more time. Letting things blow up in production and guilt tripping them into late night debugging sessions costs nothing.

It’s a false economy anyway. You’ll end up with lower team morale and a bunch of disgruntled developers ready to jump the ship. And cost of fixing that could be more than what was gained with the free bug fixes.

Kshitiz Sharma
  • 131
  • 4
3

Kudos to Robert Grant for pointing out the difference between a contractor and a fixed price contract, that jumped out at me too. Even as a contractor billing by the hour I've done work for free a couple times (an hour at $120/hr on 2 occasions) but for reasons of my own for good clients.

As an employee, unpaid overtime leads to job searches on company time and workplace theft.

OP: Have you considered this thought experiment? Flip the process and pay the developers for bug fixes, but have them write code on their own time. Silly, right?

Gus Mueller
  • 31
  • 1
2

You can make a remarkable number of approaches work. I generally agree with the rest of the answers here: the idea of trying to demand that developers fix their bugs off-the-clock is a bad way to do things. However, for sake of argument, let's say this is a reality. Can it still work? Of course. There's even a model for this:

Contractors.

What your company has done is turn all of their employees into contractors. If the employee has to finish the task on their own time (for bugs or any other reason), then they are being paid as a contractor. They get paid for the quoted number of hours, and if it takes more hours to do the job, they have to eat that cost.

This approach moves risk off of the business onto the contractor (or, in your case, the employee). Contractors are compensated for this risk: they charge higher $/hr rates because they are assuming that risk. They also typically have contracts to bound that risk (if you go on the graphic artists stack exchange, there's dozens of examples of how to write support contracts that don't burn you out).

How much are they paying their employees? Are they paying contractor rates? If so, expecting contractor grade performance is reasonable. If they are paying more typical employee rates, then they should not be expecting their employees to assume risk as though they were a contractor.

Cort Ammon
  • 302
  • 1
  • 4
  • 4
    That's not contractors, it's fixed price contracts. Contractors will often have a fixed time and cost, but not fixed scope; you hire someone on a six-month contract and give them work to do in that time. – Rob Grant Aug 04 '16 at 22:56
  • In the UK, with the IR35 legislation, when I have delivered a bug that has been found late in the release process I jumped at the chance to fix in my own time. It was evidence that I was not a disguised employee, but a genuine independent contractor. – Michael Shaw Aug 04 '16 at 23:15
  • 1
    You mean freelancers. it is a good point, but the key difference is that the freelancer sets the price and agrees the work upfront – Ewan Aug 05 '16 at 09:14
1

The bugs are symptoms. Not the programmers are bad but the management and technical system. Someone with are very mechanical, inhuman thinking must have invented or decided over this.

The developers will not learn how to improve but how to hide their bugs and not getting caught. This is simple psychology and even children, cats and dogs behave so. In the long run they will create a messy code hell. Find the reason why they make bugs and solve the underlying problems. As the PM work with the devs and not against them. Give them time, education, chances to learn and share their knowledge. Care for documentation as a source of knowledge. Such a complex system requires a profound understanding. Think of refactoring to make the system less error prone.

John Doe IV
  • 153
  • 5
0

I'm not a PM. I'm a developer.

But we've partially solved that problem in an interesting way where I work. We have a team dedicated to new development. They're agile, and don't get distracted by bugs.

We have a separate team dedicated to bug fixing. That team isn't agile. We just take things in stride and are constantly being interrupted.

So, this doesn't solve the accountability problem, but it does prevent the main dev team from becoming dissatisfied and frustrated. Although, the side effect is you do have to have a small team that takes on the brunt of the stress. Those positions are hard to fill.

David Mulder
  • 109
  • 16
    Of course they are hard to fill. The 'bug fixing' developers have to learn how the code was intended to work (I'm guessing without interrupting the 'new development' developers?), make it work that way, and then see the same bug repeatedly because the original developers never learn - this setup has cut the feedback loop that would educate them. – Technophile Aug 04 '16 at 19:24
  • It's interesting though. The philosophy "the person who created the bug must fix it" can't be absolute because, aside from practical issues of availability, that siloes knowledge in each component. Meanwhile this approach siloes knowledge perpendicular to that. The developers might know about all the different components of the system but they all typo the arguments of memcpy in the wrong order some percentage of the time. They never learn by suffering that this is a bad thing, and none of them can work the debugger ;-) – Steve Jessop Aug 09 '16 at 16:36
0

Bugs are your deliverables. You should not be afraid of them or make anyone afraid. You should be embracing them, encouraging everybody to find and report them, as much as possible. You should never punish your team or programmers for bugs! That would be a terrible mistake. Watch this video: https://www.youtube.com/watch?v=7DYr8GYzJ6Q

yegor256
  • 7,050
  • 4
  • 29
  • 50
0

The problem you describe seems to be going on for some time in your work team. Are your engineers paid 1 1/2 their salary in off time or more? It is time to act right now not to enter a pattern in your work team that will be more difficult to correct in the next few years. Management studies show that it is not the salary that is the No 1 factor influencing the motivation of employees/workers. It is the quality of their work environment. People prefer to have a job where they can accomplish themselves before wanting an higher salary. You describe your tasks in the development of your products as complex causing more bugs that you would wish. Programming in 2018 is not the same thing as in the early 1980s when I took a course of Basic programming language before doing my studies in Business Administration till I got my MBA. Bugs in computer programs have less reasons to exist now than before because we have reached a degree of technology never seen before. Solving bugs is not the task the most interesting for an engineer to do. Maybe you could select or hire a few people that do only debugging; people that likes that. That move can frustrate your team of engineers. It would not be a bad thing. You have to send a clear message that you are not satisfied at all with what is going on before it's too late. Most people in North America spend more than what they earn. You can have a serious negative reaction from your engineers if they absolutely need the extra money. Also, sometimes, the members of a team sabotage their own work to get rid of their manager. Do not wait till you get there. Today, you have simulators to see if your programs work; what I understand is that certain members of your team leave unsolved the bugs they find or create. Project management, working as a team with a budget and tight deadlines need constant control of the procedures. Business administration is to plan, to organize, to direct and to evaluate/control. Since the past two decades some heresies entered management. Some people do not tolerate that their work is evaluated and controlled. My point is that you must act quickly before an exceptional procedure like working off hours become the norm in your enterprise.

0

Are there any experienced project managers out there with some words of wisdom to share on this topic?

As expected, all the other answers predictable yelled "absurd!" but not a lot of alternatives were proposed. After all, it is frustrating for management to deal with "the operation was successful, but the patient died", or, in our case "the code is complete, but it doesn't work".

What we have done is shrink the teams to 2-3 developers and a dedicated QA resource. This way a "unit of development" is incomplete as long as QA hasn't approved it. Since QA and the developers work hand-in-hand, it's not one against the other, it's teamwork aiming for perfection.

To be fully released, the item also have to survive the automated testing run, which is updated continuously to include all the new features.

This ensures that your "perfect" feature isn't breaking anything else.

As a result we have more teams, thus more management overhead. We have more QA resources. We have a slower cadence. But, when the "unit of development" is complete the quality is better.

Danny Schoemann
  • 4,542
  • 3
  • 25
  • 45