When I first heard about about the concept of a net negative producing programer (nnpp), I immediatly said: "Yep, I know what you are talking about." But after some time I started to wonder: how do these get into the career of software development, and possibly more important, how do they manage to stay there? And after a little thinking I came to the conclusion, that it is actually the 'fault' of highly productive developers, just like you probably are if you are a software developer at all.

Ok, it is not all your fault. There are developers that are just new to the craft and havened realized that software development just isn't the right job for them. I hardly can blame you for that.

But there is a different kind of nnpp. The kind that has some real values in many projects and then suddenly in a new project becomes a net negative one. How can this happen? This is my explanation:

Although we strive to reduce code duplication, in pretty much every project there is some code duplication. Taking an example from a current project, in order to create CRUD functionality for a new domain object, we have to create a class for the domain object a class for a transport object to transfer it from server to client and a class representing the object in the client. These three classes are similiar but not the same. If you have two or three sets of such classes any mediocer developer will be able add another set and move the project forward. This leads to a typical seperation between developers: The one group of developers does the repetetive tasks just described, and the more capable developers do more difficult tasks, i.e. implementing features which are more or less completely new inside the project.

But the whole game changes when you get a couple of really strong developers on the team: They will just not accept that you have to do such a repetitive task and will come up with a solution, e.g. an internal or external DSL in order to create these artefactes. That's a great thing for the project, because now creating three classes (and possibly creating a search, create, save and delete action) got just replaced by creating on simple artifact. This will save a lot of work, and when well done will allow easy refactoring of the classes, so the app stays nice, clean and flexible.

But for not so good developers this might be actually bad news: There is less work which he can solve by copying an existing piece of code. When he is working with the DSL simple Java skills (or whatever your main development language is) won't help much, because soon he will be faced with code working on an abstraction level so high that he can't deal with it, e.g. reflective code creating dynamic classes from an instance of an internal DSL.

So what is left for him is creating instances of the DSL which won't need much time. A soon as he tries to move further he will likely do more damage then good since he just doesn't understand the code and the level of abstraction used. So after trying to solve a problem and finally getting stuck a more seasoned developer comes along and now has to solve the original problem, but before that he has to understand what the first developer did, and probably undo it. Congratulations, at this point you have a net negative producing developer.

He wasn't net negative all the time and he didn't suddenly start to become dumb.

He just failed to move forward as fast as his surroundings.

So assuming you are one of the developers turning others into net negative developers. What should you do? Should you stop introducing high level abstractions to make the code simpler to maintain (for you and developers like you)? I don't think so. Make sure you are not creating accidential complexity. If you avoid that the project will move faster even when some net negative developers limit their work on what they understand reasonably well and just sit around in the time left.

As someone responsible for the overall success of the development process (project manager, team member in a scrum team ..) what should you do?

I can't guarantee it will work, but these are my ideas: First setup your team so that the difference between the best and the worst developer is small. If the difference isn't that big, the slower developer will be more likely to understand most if not all of what the fast developers do. If the difference is to big, it might make sense to split the project in two subprojects. One critical, difficult and easy, less critical. And of course you can and should invest in training and coaching the weaker developers so they don't loose in the race for knowledge.