Rapid Development - The Classics
I’ve been reading Rapid Development. I must say that my initial reaction to the first few chapters is basically depression. One of the chapters focuses on “Classic Mistakes”.
I’m depressed because a) I’ve experienced almost each and every one of the classics and b) because I don’t see anything that is preventing them from happening again.
I thought I would post my version of some of the classics. So here goes mistake number 1.
One of the classics: Not getting rid of problem people early
I had this one twice in the same project (sigh). Basically we had an individual assigned to do a core piece of work on a project. I wasn’t the tech lead, but I was the senior developer on the team so I took it upon myself to keep track of what was going on. This dev decided he knew the right way to tackle the problem. When a few of use got together to discuss his design it became clear that his vision wouldn’t work and we told him why. He ignored us and continued. I took it to the tech lead, who worked for the same contracting company that the dev did (and was his friend). He spoke to him and still the dev insisted he was right and was allowed to continue.
At this point I decided I had enough. I’m not very good at keeping out of something when I see it is really screwed up. Myself and the other senior dev split the work between us and developed the solution on the side. When we were done (with both our assigned work and this other dev’s work) we went to the tech lead and explained what we had done. We showed the finished product. He thought about it and acknowledged that we were probably right. He pulled the other dev into the meeting and asked him to show his efforts. His code wasn’t complete and he still had a lot of work to finish. The tech lead decided that we would go with our code and toss the code that this other developer just spent 2+ months working on. The dev was pissed because he was kept in the dark. I was pissed because I had told them this was a problem at the get go and nothing was done. This dev had good skills and would have been useful working on something productive instead of just spinning his wheels.
As it happens this project had yet another contractor that was added a few weeks into the schedule. He was from a different contracting company. He was assigned a relatively minor piece of functionality. It was critical to the entire app, but minor in that it was just two pages and the supporting code. After a few weeks of coding he asked me to look at something. When I looked I noticed that he hadn’t gotten very far and that all his code used inline SQL. I explained that he must use stored procedures. He nodded and said something along the lines of I’ll get to that once it works. Later in the conversation it because clear that he had little understanding of ADO and didn’t know how to call stored procedures. I dug in a little more and decided that this guy simply didn’t have the skills necessary to complete the project. Once more I went to the tech lead and made my case. He agreed it was a problem and spoke to the developer.
Weeks went by and I continued to watch what this dev was doing. I already had my work plus half of another’s on my plate so there was no way I could do more. The dev still hadn’t finished the pages, let alone got the inline SQL out. I again went to the tech lead. He once more talked to the dev. He finally concurred with me that the guy had to go. He asked to have him removed and management refused. A week before QA I demoed the product to the business. It came out that their vision of how pricing was supposed to work didn’t match what they really wanted—big surprise. The project was pushed 3 weeks so I could rewrite the pricing engine to meet their new rules. The ADO dev was removed and his work was given to another developer (who just happened to be the one who we took work away from before).
So in one project I had two cases of developers who cost the company a lot of money because the individuals managing the projects couldn’t or wouldn’t remove individual even though they were obviously causing problems.