Working as a contractor opened my eyes to the developer food chain. Even though I had similar experiences earlier in my career, the challenges seemed much more vivid this time through. I thought I’d share a couple of experiences with you, and the lessons that can be taken from them. Lesson 1: Beware of the “funnel” guy. The funnel guy is the one who wants you to funnel all thoughts, ideas and code changes through him. He may say it’s because he wants to avoid conflicts in source control, but the real reason is likely that he wants to hide your contributions. Here’s an example. When I finally got access to the code on one of my projects, I was told by the developer that I had to funnel all of my changes through him. There were 4 of us coding on the project, but only 2 of us working on the UI. The other 2 were working on a separate application, but part of the overall project. So I figured, I’ll check it into SVN, he reviews and accepts then merges in. Not even close. I didn’t even have checkin rights to SVN, I had to email my changes to the developer so he could check those changes in. Lesson 2: If you point out flaws in code to someone supposedly ‘higher’ than you in the developer chain, they’re going to get defensive. My first task on this project was to review the code, familiarize myself with it. So of course, that’s what I did. And in familiarizing myself with it, I saw so many bad practices and code smells that I immediately started coming up with solutions to fix it. Of course, when I reviewed these changes with the developer (guy who originally wrote the code), he smiled and nodded and said, we can’t make those changes now, it’s too destabilizing. I recommended we create a new branch and start working on refactoring, but branching was a new concept for this guy and he was worried we would somehow break SVN. How about some concrete examples? I started out by recommending we remove NUnit dependency and tests from the application project, and create a separate Unit testing project. This was met with a little bit of resistance because - “How do I access the private methods?” As it turned out there weren’t really any private methods that weren’t exposed by public methods, so I quickly calmed this fear. Win 1 Loss 0 Next, I recommended that all of the File IO access be wrapped in Using clauses, or at least properly wrapped in try catch finally. This recommendation was accepted.. but never implemented. Win 2 Loss 1 Next recommendation was to refactor the command pattern implementation. The command pattern was implemented, but it wasn’t really necessary for the application. More over, the fact that we had 100 different command classes, each with it’s own specific command parameters class, made maintenance a huge hassle. The same code repeated over and over and over. This recommendation was declined, the code was too fragile and this change would destabilize it. I couldn’t disagree, though it was the commands themselves in many cases that were fragile. Win 2 Loss 2 Next recommendation was to aid performance (and responsiveness) of the application by using asynchronous service calls. This on was accepted. Win 2 Loss 3 If you’re paying any attention, you’re wondering why the async service calls was scored as a loss.. Let me explain. The service call was made using the async pattern. Followed by a thread.sleep <facepalm>. Now it’s easy to be harsh on this kind of code, especially if you’re an experienced developer. But I understood how most of this happened. One junior guy, working as hard as he can to build his first real world application, with little or no guidance from anyone else. He had his pattern book and theory of programming to help him, but no real world experience. He didn’t know how difficult it would be to trace the crashes to the coding issues above, but he will one day. The part that amazed me was the management position that “this guy should be a team lead, because he’s worked so hard”. I’m all for rewarding hard work, but when you reward someone by promoting them past the point of their competence, you’re setting yourself and them up for failure. And that’s lesson 3. Just because you’ve got a hard worker, doesn’t mean he should be leading a development project. If you’re a junior guy busting your ass, keep at it. I encourage you to try new things, but most importantly to learn from your mistakes. And correct your mistakes. And if someone else looks at your code and shows you a laundry list of things that should be done differently, don’t take it personally – they’re really trying to help you. And if you’re a senior guy, working with a junior guy, it’s your duty to point out the flaws in the code. Even if it does make you the bad guy. And while I’ve used “guy” above, I mean both men and women. And in some cases mutant dinosaurs.
