We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

77

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 ...


51

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 ...


45

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 ...


27

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 ...


17

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 ...


15

When Engineering Problems Become Project Management Problems One of the team members turns in code that is almost always bloated and inefficient, even though it technically works (although, from time to time it doesn't). This is only peripherally a project management issue. It is actually an engineering issue, but it bleeds into project management ...


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 ...


13

“It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. Sherlock Holmes A logical corollary is that it is a capital mistake to devise risk mitigation strategies before stating a risk. There is no risk in your question. Your client wants to compress UAT. Before ...


12

If you are building a product for a client, your internal testing / QC work is not subject to negotiations. It is part of the work, part of the price, and there is no reduction in that area. If the client does not want to conduct UAT, that's their choice and risk to accept; however, there's secondary risk on the seller in this scenario. To mitigate the ...


9

"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 ...


8

It's great to hear that Code Reviews went smoothly and you are seeing results soon, you have seen it's effective and that means the junior programmer is keen to learn (All good stuff) Few things I would like to suggest which can be done at your end Good code samples from existing code base - You probably have some star quality code in your existing code ...


7

The Product Owner has responsibility for the backlog and the development team has responsibility for delivery. However, in Scrum we work as a team and there is nothing to stop the Product Owner discussing concerns over delivery with the development team. Just as there is nothing to stop the development team discussing concerns over the backlog with the ...


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 ...


6

Using historical data As the others have said, you'll need to estimate future outcomes, based on historical models. For best results, you need to do this with your own records. However, for benchmarking and validation, you can also look into buying extracts from commercially-available databases of software project metrics. QSM Project Database SPR ...


6

Given the example you gave, no quality management methodology can be applied. Indeed, quality management is all about continuously improving the output quality (not only, but as an abstract overview, it is sufficient). This definition would itself need to be more properly defined regarding against which metric improvement would be measured, what is the ...


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 ...


6

We've struggled with the same issue on my team, while there's no replacement for a quality QA on the team, we've managed to get along by wearing multiple hats. This is our workflow: TDD the story until it's ready to integrate. Developer integrates and manually tests. Developer requests code review. 2nd dev reviews the code. 2nd dev pulls the changes ...


6

This sounds like a good topic to bring up at the team's retrospective. There are lots of possible approaches, but the team should decide for themselves. Some things you might consider: The QA shows bugs to the Product Owner before they log them If a bug is not viewed as important by the Product Owner, resolve it as 'won't fix' Discuss as a team the types ...


5

If I don't have the time to produce a Swiss precision watch, ... If I don't have the tools to produce a Swiss precision watch, ... If I cannot attract the people that can produce a Swiss precision watch,... ... I might end up offering sun dials. Likewise, my customer might not have the time to actually figure out the difference between a sundial and a ...


5

Having gone through something similar myself, here are some considerations. I'll try not to get too wordy but there are some aspects of Scrum that need to be brought up. Making this sort of change can be extremely beneficial, but first and foremost needs buy-in from the developers. If they are not supporting changes it won't work, and Scrum should be run ...


5

TL;DR While quality can be measured objectively, defining the domain-specific elements of quality for your organization isn’t something where you can rely on a standard dictionary definition. In fact, most of the issues you’ve identified aren’t intriniscally quality issues at all. They seem more like organizational issues. We’ll look at some of them in ...


5

Discuss in the Retrospective. There's a limit to how much advice can be obtained from strangers on the internet. Your Team is presumably aware of the problem, and Scrum prescribes a self-organizing Team. So discuss the issue and brainstorm/evaluate possible solutions during the Retrospective. That being said... Have QA be involved during the Planning ...


4

Actually, I'm using only two KPIs: number of users/customers: as a goal, we define how many users or customers we would like to have during a certain period. For example, we want 30,000 new customers in this year the time we need to deliver a new feature: in other words the lead time. We check our actual lead time and see check whether this time is enough ...


4

Focus on quality and estimates You identified four problems. Of those, I would view the following two as your main issues (long hours and missed deadlines are likely resulting from these): Quality of your code is dropping: When the quality is bad, you end up doing a lot of unplanned work. This results in long hours and missed deadlines not to forget the ...


4

TL;DR Should I add something to "Client Obligations" about code style? You can do this, but you may be measuring the wrong thing. This smells like an X/Y problem: you have a problem to solve with the deliverables hand-off, have decided that coding style is the thing that will fix the problem, and are now trying to solve for "coding style" rather than the ...


4

From a technical standpoint, code metrics should be baked into your test-driven development (TDD) or acceptance testing, preferably in an a fully-automated way. However, from a Scrum perspective, the framework is not prescriptive. The correct framework perspective is that gathering and checking your current code quality metrics should be part of your ...


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 ...


4

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 ...


4

So right now, as an Engineer, I take a single task, mull over it for 4 weeks, make sure it contains no bugs at all and I am the best worker you ever had. Despite the fact that it took me 4 weeks to deliver such a simple task. On the other hand, you have QA, who is wildly dependent on getting a crappy Engineer assigned. The crappier the engineer, the more ...


4

In a Scrum team it is best to distinguish between roles and capabilities. Every Scrum team needs a testing capability, but it does not necessarily need tester roles. The whole Scrum team takes responsibility for quality. This means more than just testing, it also means: Automated regression tests Maintaining code quality Use of continuous integration ...


Only top voted, non community-wiki answers of a minimum length are eligible