Software Development Project Management: Take 1

For the sake of documenting some of the processes or set-ups I'm using for the project I'm working on at work (which I will refer to as BS.NET Project), I'm going to try post stuff here to that end.

Primarily what I'm pushing towards is an 'everyone for everything' approach. Not to say that all developers working on the project will be working on all parts of it, but I do want everyone to have a deep enough understanding of the whole project such that at any time they can work on any part of it that is needed.

This is actually quite a tall order in the context of the company that I'm working for. The developers there (and I'm sorry to say both new and old) don't have a strong feeling of 'shared ownership'. I.e. that the code belongs to no-one and everyone at the same time. That is to say that everyone is equally responsible for all the code. Viewing the code as one inseparable unit of ownership and not fragmented parts written and maintained by separate developers. Not to say that any one won't have their area of expertise, but rather that no-one will be confined to their area of expertise and that given the right circumstances, their areas of expertise will grow.

My hope is that I will accomplish this by getting developers to work on many small chunks of the project in parallel as opposed to splitting work into large ones. So, let’s say that tasks A, B, C and D are related, and 1, 2, 3 and 4 are related. Instead of getting one developer to work on ABCD and another on 1234, I’m going to get one to work on AB and one on CD, then the first on 12 and the second on 34. Yes, I appreciate that I’ll be missing out on specialization of labour, and the efficiencies of that, but I believe primarily specialization has the tendency to dumb the mind resulting in potentially good refactoring chances being missed, and secondly, in the long term, this approach will result in greater capacity to maintain code and to avoid resource bottlenecks (i.e. one developer holding up a project because he is over allocated, but no-one else can do his job).

I want to get across the way to prevent code from breaking when someone other than the person who wrote it working on it is unit tests. Getting across the idea that the way to manage changing requirements leading to changes in the code such as not to introduce bugs, isn't by having everyone working on and being responsible for 'their' code, but instead everyone providing tests for code they have written that verifies that that code does what it should. If we can develop a standard for testing various parts of the system, then we can be more confident when it comes to changing them.

On the other hand I do believe that you can over test. That is to say at the end of the day it all boils down to money. There comes a point when the cost (in terms of man-hours) of writing extra tests to iron out another 50 percent of bugs isn't worth it. For example, let’s say with 1 unit of time we can iron out 50% of bugs in a project. And for the sake of argument, let’s say that this is constant. 1unit of time = 50%of bugs, 2 units = 75% of bugs (50% of the 50% left), 3 units = 87.5%, 4units = 93.75... And so on. It should be clear that there comes a point where the absolute number of bugs found isn't work an extra unit of time. The trick is finding where this point is: and in general, it depends on the nature of the system. If it’s a safety critical maybe you need to have a 99.9% bugs eradicated. If it’s a finance system, maybe you can live with 3% bug, and if it’s a game maybe you can do with 8% bugs. In practice I guess you never know how many bugs are in the system, but you do know how much it costs to catch the next bug. From my point of view, I have to guestimate how much our boss is prepared to live with such that he allows a Test Driven Development approach without getting pissed off at the perceived time it is taking (I say perceived, because convincing him the time will be made up when it comes to testing it and supporting it is an equally difficult task)

In order to get everyone working on everything smoothly, I definitely need a source control setup and I've decided to try a continuous integration setup too. I want developers to know how to use the source control tool, and what their responsibilities towards it are. I don't want them to be constrained by it or afraid of it. I want the CI process to run unit tests and to check code coverage. I need to think about configuration management and thus define a build process, a release process and a versioning policy. I would also like to eventually introduce an issue tracking system to better bring together support, development and management but define a process for its use and make sure that users are familiar with it and understand that is isn't an extended e-mail system.