Negative work

Published On: Dec 29, 2016

Every once in a while you get the opportunity to work with people who really make the process of writing software really nice. People who know the right patterns to build the right type of software, those are the projects that are almost over as quickly as they start, if you have never had the experience of working with one of these people you are really missing out… but this post isn’t about them.

This post is about the people whose contribution to a project can be felt in a negative way long after they are gone. These are the people who leave little treats all over the code base just waiting for someone to trip up on their code. The find the worst parts that you have been trying to phase out and make them the core components of their new work. They are the people who never submit code reviews, the people who never right unit tests, the developers who think that they should just write the bare minimum needed to get the code to execute then they call their work done, assuming that the person who is going to be dealing with their code when it goes to production will be long gone.

In the past I have worked on projects where the mentality is that everyone needs to be working, so when there is availability they move developers to projects to make them chargeable. The problem is that you never pick up good developers this way, why? The answer is simple, good developers are usually struggling to keep the broken project that they are working on together. Talented developers get into a habit of moving from one fire storm to another in the consulting world, because of their skill they usually demand a higher bill rate which means that when things are going well most businesses see them as the first thing to cut, since they are so expensive. At least thats how it works in the consulting world. But I digress…

The problem is that when you take a bad developer and add them to a system that either has a lot of problems (that are in the process of being fixed) or is in the early stages. Both of these are extremely dangerous in the fact that their impact unchecked can have disastrous consequences downstream… take this as an example found in the code of a peer.

    var loadIndices = function() {
        indexFactory.get(function (data) {
            var firstIdx = true;
            data = data || {};
            data.indexDetails = data.indexDetails || {};
            angular.forEach(data.indexDetails, function (data) {
                data.isOpen = firstIdx;
                data.isDisabled = false;
                indexFactory.getFields(function (returnData) {
                    data.fields = returnData.fields;
                }, data.indexName);
                firstIdx = false;

Example #1: Wait so where is data scoped ???

The reality is explained in the breakdown of time for another item that was included in the same project.

Time for developer to do work: 16 hours
Time for me to code review: 1 hours
Time for developer to update bad code: 3 hours
Time for me to track down bug that slipped past: 4 hours
Time for me to track down bug related to settings not being configurable: 4 hours
Time for me to change Dictionary<string,string> to message: 15 hours

Example #2: Actual time spent cleaning up a poor design choice ???