Scott Leberknight's Weblog

I have a friend who works on a project with a manager who typifies the problems with the software development industry. We'll call this developer Bob and the manager Jim. Over the past couple of months Bob has mentioned some very disturbing things that Jim has said and done in running, if one could call it that, the project. For example, Jim started off by not allowing Bob, the lead developer, to use a persistence framework and instead mandated he use straight JDBC because of the "risks" of the frameworks. This is of course nonsense since the real risk is not using a tried and true persistence framework and rolling your own.

Another brilliant decree made by Jim was that developers cannot spend time developing unit tests because they will slow the development effort and are not really needed because the developers "are very careful to write bug-free code". Excuse me? Did I just actually hear that? Yes in fact I did. As a developer I am careful to not introduce bugs into my designs and code, but I in no way do I assume I write bug-free code. Unit tests of course are one way to ensure high-quality code and in fact speed development, since many bugs are caught and fixed much earlier than they otherwise would be. In addition, a quality suite of unit tests that can be run at the touch of a button are wonderful for regression testing new changes. Even worse, Jim told the customer that the developers were very careful to write bug-free code and that they would only need one week to fix any and all bugs that were found by the integration testers and the customers! Bob was not at all pleased to hear this of course.

Another fun thing Jim has done on several occasions is to inform the customer that the developers intended to be done early, so some additional new requirements could easily be added. In reality, Bob told me many times there was no way they were even going to meet their original deadline much less with loads of new requirements. Finally after recognizing they were not going to make the initial (unrealistic) deadline, Jim got the customer to extend the deadline several months. Then Jim did something that Fred Brooks would, I am sure, not advocate. Jim told Bob that since they had a few more months, this would be the perfect time to bring on five more developers to "speed up development". So much for Brooks truism that adding developers to a late project makes it later, whcich has been proven out over several decades.

In the end, Bob has started looking around for other projects and probably not be with that project much longer.