6

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.

  • Can you tell us a bit more about the kind of mistake they do and the way they work ? And how many they are ? – Pierre Feb 22 '14 at 2:39
  • Maybe related (at least worth reading): pm.stackexchange.com/questions/5757/… – Tiago Cardoso Feb 22 '14 at 3:08
  • 1
    @Pierre 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. – saakian Feb 22 '14 at 10:18
  • Okay so it's a bit subtle and I have yet to integrate these concerns into my own work (performance is secondary in our applications). I know that you can give them contracts for each feature and automate the tests: if a file generation must not take more than 4 minutes, you tell them, they implement auto testing (so no QA phase yet: they need to know it's wrong while coding a long time before QA) and they can't commit the code to QA before every constraint is respected ! In your case, performance IS a feature, they have to understand that ! – Pierre Feb 22 '14 at 10:47
  • You make it sound like the problem lies with these junior developers, when to me it sounds like it lies with your processes. You might be "analyzing" these things too late in your project plan, not be planning enough slack time accounting for your developer's experience levels, and not be documenting and conveying these non-functional requirements correctly. You say you do, but if that only appears later, then I'd say the problem lies in your process, and it should have been detected earlier. – haylem Feb 27 '14 at 18:35
5

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.

  • yes me the words ''all'' and ''always'' are a little bit exaggerated, but if in 80% of cases it works why should not I assume that it should work in 100% of cases? It is very hard to conduct case-by-case analysis especially in large teams. – saakian Feb 22 '14 at 10:45
  • as you 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'' . Completely agreed. but what about if devs have these abilities. What will you do to fix the situation? your answer is very interesting, please include this question too in your answer – saakian Feb 22 '14 at 17:54
8

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

  • 2
    Hello Pierre! I liked your approach (and the fact you're sharing your experience from a different standpoint!) and I believe you have room to transform your good answer into a great answer by presenting what could be done, like having the Devs presenting the test cases they want to run, how they intend to test their codes and so on. Here goes my +1! – Tiago Cardoso Feb 22 '14 at 3:13
  • Thanks ! I'll try to think about a more precise answer then ! – Pierre Feb 22 '14 at 9:56
  • @TiagoCardoso is this really a good idea having Devs presenting test cases? Have you ever done in similar way? – saakian Feb 22 '14 at 10:22
  • @Pierre yes if it is possible we would like to see more precise answer. Although forcing the team to do more tests is a very good idea, +1 for this – saakian Feb 22 '14 at 10:24
  • 1
    @saakyan Indeed and I'm not so sure myself. I know that if I only think about code I code poorly from a end-result standpoint, but I don't know if people have success only being great technical devs who make no mistakes. – Pierre Feb 22 '14 at 11:20
4

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.

  • 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. Thanks! – saakian Feb 24 '14 at 13:48
  • What will you do in this case? Please include this in your answer. I am sure it will be very helpful – saakian Feb 24 '14 at 13:48
  • If the NFRs are documented, but the developers fail to deliver against them, then you need to know that is the case during your System and Integration testing, not in final testing or production. This points the fact that maybe your integration test environment is not up to the job and does not adequately mimic your live environment. If it was then your testing should show that the NFRs have not been delivered. You would deal with this in the same way as any developer consistantly failing to deliver on their requirements and that is a subject for a different question I believe. Hope that helps – Marv Mills Feb 24 '14 at 14:20
  • The copy-paste and minimal-coding practices that your developers are using are GOOD, as they get you the most value for your developers' time. Optimizing performance is difficult, so you should only do so where there is pay-off. As such, it is critical that you specify what is acceptable performance, and then perform testing early on to identify where code is causing unacceptable performance degradation. One big lesson: running code against 100 test records for one user is completely different than running it against 100,000 records in production for 200 concurrent users. – Dane Feb 27 '14 at 16:25
3

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.

2

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.

  • David I see now you're already on this thread LOL – Joshua McFarren Feb 21 '14 at 16:05
2

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

1

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.

  • 1-yes we do that and very strictly. 2- although it is very useful to review the code, but we do not do this if the dev is not junior anymore.besides, in case the deadline is approaching , that would be a luxurious thing for us.3- may be very helpful +1 for this – saakian Feb 22 '14 at 10:37
  • 1
    Currently, we only have seriously senior developers in my team – and we review pretty much everything. Simple things by sending a link to the commit after the fact, anything not simple is reviewed pre-commit. Even if you ignore the effect on code quality, it certainly increases the bus factor, which in itself would be enough to make it worth doing. – Christopher Creutzig Feb 23 '14 at 17:49
  • @ChristopherCreutzig thanks! of course codes review is very important. now, I am considering to conduct sometimes code reviews for senior devs too – saakian Feb 24 '14 at 14:01
1

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?

  • thanks! yes performance is the main concern of all of my projects. But that is just one of the problem I cited. I just noticed that we encounter the same kind of problems across many projects. e.g. there are some devs whose code causes problems. As I said, it becomes like a trend, so that I have to fix it. – saakian Feb 24 '14 at 14:42
  • CodeGnome's Law... This I have to see... Is there a link? :) – Marv Mills Feb 25 '14 at 12:13
  • CodeGnome's law roughly states that it is a cardinal error to automate that which you do not understand. Seems like an obvious, even trivial statement, but it keeps cropping up in PM:SE. – Mark C. Wallace Feb 25 '14 at 12:17
  • Totally agree... The amount of times I have had to stop people going straight to process automation and made them analyse and document the full as-is process first, then and only then think about how you might systemize/automate that process... They never learn :) Henceforth I will adopt the correct name for this- CodeGnome's Law :) – Marv Mills Feb 27 '14 at 17:20
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.