Best way to deal with developers whose work is always unsatisfactory

Question

The problem is not in experience,

The developers have all the necessary resources to work in a good dev environment (time, books, assistance, team leads, technical leads, senior devs, project managers).

However, there are always serious problems in their work and I am forced to assign senior devs to check and fix the errors.

I have tried to say them directly about that, but this an inefficient way to deal with the problem.

Bugs are too specific to assign and wait for the solution as the problem lies in overall approach to software development process.

Anyone can help to apply some methods for efficiently solving the problem?

Additional information from comments

One of the major mistake they do is not apparent. If QA tests the system, all the features work right and in accordance with requirements. But, the performance sucks, which has its deep roots in code. When we analyze the code, we find that there are scripts which take much time to run, plugins which were copy-pasted without optimizing etc. Usually, we leave the devs complete freedom in implementation stage if they are not junior anymore (from a clarification in the comments)

most of the functional and non-functional requirements are well documented and daily meetings are held so that everyone understands how the system should behave. Most problems arise when the software is already in overall system testing stage or in production. Then, while analyzing we find that the dev has used short, but inefficient way to obtain a feature OR plugins were used which were not customized for the current project. It comes out that it is not a bug but insufficient attention and responsibility, which becomes a trend if I do not fix that.

Answer 1

The developers have all the necessary resources to work in a good dev environment (time, books, assistance, team leads, technical leads, senior devs, project managers).

There are a lot of drivers to performance issues including many you will not identify. In an almost knee-jerk fashion, we have a tendency to blame the human and overlook the many other drivers. We replace the human but then get the same or similar results. While you indicate they have "all" the necessary resources, I would suggest really analyzing your project capabilities from the total system of process & procedures, tools, skills of the human resources, and intellectual capital. I suggest this because of the word "all" and "always," which suggests perfection and we never really get to perfection, either perfectly great or perfectly poor. So it leads me to believe your assessment is biased against the individual developers.

That said, if you rule out everything else and determine you have individuals who do not have the resident knowledge, skills, and abilities to perform, then you need to replace them. Unlike an operations where you may be compelled to "grow" a resource into a higher performer, on a project, you do not have that luxury of time, nor should a customer pay for that growth. If an enabler is under performing, replace and keep going.

EDIT: No one every performs with 100% success. Individual performance, even the hyper performers and superstars who walk among us, will bounce it in every now and again. I am not sure how you are measuring the 80% versus 100% but either way you must accept defects in work performance from everyone. Your PM capabilities, specifically your risk management and quality management processes, should be designed with that in mind such that the defect can be addressed before delivery and in some cases after.

If you look at your pool of developers, it is very likely they could have the resident knowledge, skills, and abilities to perform, but that does not make them automatically great performers or even acceptable performers. As an example, the captain of the Colgan Airlines airplane that stalled over NY a few years back had all the credentials and experience but he was always a low performing pilot. What you have to determine is if you think you can fix their performance to be acceptable in a reasonable amount of time before your customer and your reputation goes south. If you can, train; have a better performer shadow them as they do their work. If you can't, replace. If you can't replace, then escalate to your boss your risk and document everything to protect yourself.

Answer 2

As a developer in a very small team (we are two...) without senior devs to help us, I know the thing that helped us a lot was integrating quality concerns into our workflow.

We test A LOT what we do. I consider myself to be very unreliable, so I triple-check everything I do and I force my coworker to do so: we unit test many things, and integration-test everything (with Selenium for example).

We now are QA+Dev people and even if it doubles the time we spend on features, at least the application works as expected when released vs what we did before: rushing to get as many crappy features to show our boss as possible, without checking regressions or edge cases and eventually earning the reputation of bad developers :D

Edit: Better answer with a task list you could try

Without knowing much about what they exactly do wrong and the size of the team, here is what I would do in such a situation, based on my own experience with the same situation (when I arrived in my company fresh out of college, all our products were borderline crappy, with bugs everywhere, bugfixes creating more bugs than before, devs not caring, boss burned out, everyone leaving out of despair):

• Start integrating quality concerns into the development process: the devs must be committed to produce quality code, and they HAVE TO stop thinking their job is coding. Their job is 1 third specification/thinking, 1 third coding, 1 third testing.
• Make them unit test a lot of what they code, and you can gamify (always work with devs) this by measuring test coverage (even if it has downsides which we can discuss about later): you have a direct quality metric
• Make them understand the end-user constraints first: they need to know what has to happen and not interpret too much on vague descriptions made by higher ups (a huge problem in our team that we try to solve with user stories)
• Make them (or others) test the code from a "client standpoint", either via automating the user or having a guy doing checklists (very boring, automation is much better if possible). That will show them immediately how crappy their code is: the whole app simply doesn't work as intended.
• Make them do peer review: each dev is responsible for the code of another one, and has to check the new stuff from times to times: we use Atlassian Crucible/Fisheye for that and it works very well
• Use a lot of gamification metrics to give grades to the code, Sonar is a very good tool for this. For example in my team we have a grade of "76 days of technical debt" which means that for our code to be perfect we need to spend around 76 days correcting it. Of course it's only technical and it's a very vague grade but at least they have a grade. They know if they do better than the last time or not, and it becomes a game to try and lower the "debt". It give you a lot of other such metrics you can try to beat too.
• Try to make them build "end user test" documentation, that THEY will play with the end user (sorry I totally lack the english words to describe it). That will make them responsible and shameful if something doesn't work. (I work after hours when I disappoint a client with an unexpected bug vs I don't care too much if my boss just goes around and tell me "don't forget to fix this weird thing someone might one day notice")

The thing about some devs is that they think code is their job. It's because there are rhetorics everywhere about talented developers, elite programming languages, skills etc. While in reality a dev is not much more than a factory worker having to assemble pieces together. The complexity of the assembly phase is impossible to perfectly predetermine and that's where "skills" is involved, but we have to understand we do industry stuff that need to be reused, maintained, read, monitored, scrapped etc, just like in a factory (don't tell them that xD).

The quality of the work we do is much more important than finishing soon, coding like a star, learning something new. So in my very humble opinion, they lack quality concerns, and it's not so hard to make them understand. It took me 6 months to totally change the way we work, from vague oral specification to dynamic written specs transformed into tests and code. And now we even sell our products :D

Answer 3

Loads of great answers here, but the thing that leaps out at me is this:

You have said the devs deliver the functional code to a high standard- it does what was requested of it. But you have cited Non-Functional Requirements (NFRs) as the source of the issues.

Are you actually documenting your NFRs at the specification and design stages? If it is a pre-condition for acceptance that a certain function needs to perform at a certain level, then that should be documented and specified. It sounds like your dev process would deal with that successfully.

If you fail to document the NFRs you cannot then blame the developers for not producing code that meets them. You cannot just assume that devs will somehow know what is required and produce code that is performant in the right ways. If you document the NFRs then you can measure quantatively how well the development process delivers against them- if you don't then any assessment is subjective.

To be honest it sounds like you've got a good development team and are just not instructing them in the right way to deliver the required outcomes.

Answer 4

You have to have the option to roll those developers off the project if there is no progress, otherwise, just assign them as little work as possible and give those senior developers something else to do to move the ball downfield.

People who make the same mistakes over and over again require additional time and attention from yourself and others that could be best used elsewhere. There could be something else going on with those developers and their mistakes could be a sign of burnout, that they are upset about something or personal problems.

It has to be about the team, and then about being of service to the people who need the software. If you allow the situation to continue, everyone else has to work harder to pick up the slack, and the people you are ultimately serving will get less. Also, the people that have to pick up the slack are going to be frustrated with you and you will lose their respect and will be a less effective leader.

Answer 5

This is a great answer by David Espina to a similar question that was asked about a year ago: Dealing with a coworker who keeps making the same mistakes over and over

If there was a cog in your manufacturing machine that was well worn and slips and causes the rivets on your widget to be out of specs and tolerance levels, what would you do with the cog?

rbwhitaker: "but people aren't cogs...." This is the challenge, isn't it: treating people well, making them feel needed, wanted, valuable, while make the unpopular, non emotional decisions treating us human capability enablers exactly like tool enablers, system enablers, process enablers, money enablers...because that is exactly what we are. The hard, unpopular truth is companies, and their projects, do not exist so people have some place to go everyday. We are there to enable a capability, and we go away when we are no longer needed. We may not like how that sounds, but our feelings are not relevant.

The performance curve, if you believe it is normally distributed, says you will most likely have very average people on the job. Current thinking says the curve is not normally distributed at all, but instead skewed to the left, i.e., positively skewed. This means few produce the most; most produce little. These few individuals who "repeatedly" perform poorly are very unlikely they will even approach the MODE much less climb to be a high performer. They could, just not likely. It's a hard, crappy decision, but you're the PM. You HAVE to make the tough decisions. And you HAVE to consider what we know about human work behavior. And you have to deliver the goods. This means, act like a leader and replace the cog and turn the machine back on and deliver.

Answer 6

@david Espina and @Joshua McFarren have given good answers; I agree with them, but I think that it may be useful to supplement their answers based on a more projectized environment. I don't have the ability to replace anyone on my project team. They all have line managers and frequently they work for companies that aren't even under my project sponsor. If you're in a situation like mine, "replace them" is like the advice "Replace the speed of light".

What is the effect on the project?

From a purely project perspective, you've done the first step - you've assigned senior devs to doublecheck their work. The next step is to quantify that and express it to the stakeholders.

Our plan had been for N months; based on a review of the work packages completed in X/N months, we are 30% behind our plan. In order to meet our minimum quality standards, we've had to retask Y% of our senior dev's time to review the work of their peers. I'm very grateful to the senior developers, but this effectively diminishes their effectiveness. Consequently, I now predict that the completion of the project is delayed by P months at an additional cost of Q dollars.

Management may wish to consider hiring a senior dev devoted to quality assurance, which would cost less than the Q dollars estimate and even factoring in the time it would take to get the new expert up to speed, would still cost less than the Q dollar overrun that we're currently projecting. If you're interested, I can also develop some estimates of the total effect on the quality of the project and the probability that the customer will find it suitable for business need.

Answer 7

Additional things you can try

To add to what @David Espina said, you can also try the following:

1. Are you writing acceptance criteria? Acceptance criteria complement the story’s narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story and make it more precise and testable.

2. Instead of assigning senior devs to check and fix the errors (after the fact), you might try asking the senior devs to review the code for some period of time. This might give them a better insight into what is going on.

3. Set up a retrospective meeting (if you don't have one already) and ask the devs what can be done to improve the quality of work.

If none of that works, then you may have to consider more drastic measures.

Answer 8

Kudos to @MarvMills & @Pierre for peeling back a layer to more deeply understand the problem. Based on OP's clarifications in comments, I agree with Mr. Mills that the core problem is NOT the devs at all, but the process. Once again we have a variant of CodeGnome's law

OP says that the problems are performance problems that arise " . . . when the software is already in overall system testing stage or in production."

I'll make a few additional suggestions

1. Don't put code into production that you haven't load tested /performance modelled. Or perhaps more precisely, if your performance testing/modelling is your production system, capture the performance modelling you need from your operational system.

2. Insert performance tests in whatever gateway you use to move code from development to production. Create a feedback loop to adjust the nonfunctional requirements against which the devs work.

3. Elsewhere in the comments you assert that you have very strict acceptance criteria. Do those include the kind of performance problems you're experiencing?

Answer 9

First of all I don't feel that unsatisfactory developers will be at instance should be a part of a developing company. But also if there is no other option then the usage of an automated tool will be the best option in managing the developers. We are a service based industry and also keeping the track of work we have been using the cloud based task tracking tools which makes a significant difference in the operational level.