The major project that Walter dragged his ass on for six weeks is not yet complete. There was a brief and uninteresting delay in the middle that was Ideal’s fault — some logistical issues with getting the infrastructure ready — but unfortunately that has not been the only problem.

I went into work recently feeling really awful. I felt like the situation was coming to a head. I had failed to produce a working version of Emerald in an unreasonably short period of time. That was compounded by my failure to get the infrastructure project working in the six weeks I had promised it within. I felt that the perception of my work and value was in the dump, and I was dangerously close to being “downsized.”

My insecurity was vindicated when Ben asked me to his office to tell me that because of my consistent lack of results, that I was being fired.

Picking up the Pieces

Luckily for me, that situation happened in a dream last Sunday night, not the following morning when I actually came into work. I never have dreams like that, so I’m very aware of how much pressure I feel to perform. I think rationally that much of the pressure is internal. I just got a raise, I’m well-liked, and I’m generally perceived as an agent of progress. Jesper may wish I produced products more quickly, but I certainly won’t be fired for that.

I feel that this project is going to form the basis for whatever perception David is going to have of me from now on. If it works, and works well, then I win. I win big. If it’s late and it doesn’t work well, then I’m branded: Ken Sharpe is late, and doesn’t work well. I want to avoid that brand. I want to be that agent of progress that some see me as right now — a leader with a positive vision who knows how to seduce sweetly and destroy utterly when the situation calls for it.

That’s why I really vetted this project vendor, Michael, before I stuck my neck out to hire his company. In the 7 weeks that followed my decision, I have realized a few things.

Shady Software Vendors, Redux

First, Michael is a smart guy. Lesson one is that smart guys don’t always hire smart guys, and despite telling me early and often that his lead developer Praveen is a “rockstar,” a term Michael used to seduce me, Praveen is certainly no such thing.

It is clear to me now that Praveen and his team subscribe to the “it works on my machine” school of software testing. On the glorious occasions that I have seen a fatal error, the code that has spewed forth from those errors frankly scares me. I’ll spare the details for the less technically oriented but the code is alarming.

Lesson two is that I trusted them despite my reservations, and I shouldn’t have. I went into the process with high expectations, and I realize as a developer that not a lot happens visibly at first. We had our weekly meetings and we got a webcast preview of the features that were being worked on. Praveen would tell me what was done, and what was left, and although it seemed skimpy, I didn’t generally have the list in front of me, so I took his word for it. That was a mistake.

My idea was that Praveen knew what he was doing, and pointing out every possible detail to him that he didn’t mention explicitly would just aggravate him, and slow down the process. I felt that Praveen knew the things I was thinking about because those things go without saying to a great developer. He’d figure out where the gaps were and follow up with me on his own. Right?

The first 60% of the project went this way. I would see the progress, get the feeling something was missing, but let Praveen forge ahead anyway. At the 60% mark we had our local servers running correctly with all the correct permissions to the various systems, and the first version became available to tinker with. Now I could log in and play with what was being shown, not merely watch it on a webcast.

I’ve explained before about the sorry state I found the software in, and what Praveen et al did to “correct” the issues I found. I had an epiphany in those first moments, watching the spectacular and repeated failure of the team to produce a product I could use or even show to anyone internally at Ideal without feeling embarrassed.

So, in short, I uncovered my vendor’s youthful incompetence. I acted quickly, but perhaps not decisively enough. I e-mailed Michael at length — I told him what I had found, and I expressed my skepticism that the project would be ready in time, and robust enough for production use.

I’ll publish those e-mails in a near future post, and explain my strategy with those further interactions then. Right now, I’ll leave you with my advice looking back on the situation.

What I would have done differently

Knowing what I know now, I’d have approached the project very differently. First, without actually have seen a track record of impressive programming from Praveen and his team, I would not assume he was good just because someone said so. That means I would have started explaining what I wanted in painful detail very early, pointing out the various possible pitfalls and ambiguities in every request.

In addition, I would not have assumed that Praveen was keeping proper track of the features being requested. I would have set up a bug tracking system from the very beginning that his team had access to, and that I had access to.

From the very start, every tiny, insignificant feature and bug would have been documented, with available change history. There is nowhere for a developer to hide when he has a ticket in the system that was entered a month ago, documented to the second, and explained in vivid detail. There is no “mistake,” or “forget” — there is only accountability. Either I didn’t ask you for something or I didn’t ask you correctly, which is my fault, or you fumbled.

Keeping every minute task in a repository is a little like using a zoom lens to watch someone chewing food. That level of detail makes it impossible to mistake a feature or bug for anything but the nasty, complex glut that it is. There’s no way to egregiously under estimate the time each task will take if every ticket is divided into sub tasks, each taking less than 4 hours each. Every painful exception and edge case becomes uncomfortably clear, so the developer’s natural optimism will be thwarted in favor of realism.

The really important advantage such a system has is to keep everyone on the same page. If there is an understanding that once the tickets are all marked “complete,” then the vendor has completed the project in full, clients (like me in this case) tend to get really detailed about what they want, and the developers tend to ask a lot more questions to make sure the ticket is successfully completed.

Any project that lasts longer than a few days or has more than one person involved should always, always, (always) use a development ticket system to keep track of progress, and all the stateholders should make sure to use it religiously. I promise the project and the people involved will be better and happier for it.