Wrap Party

The final installment; part six of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

Six weeks go by quickly, and the project is complete. Now it's time to take a look back to see what we can learn about what went well and what did not.

As one measure of the project, I'll use Joel's test of a good software development environment:

  1. Do you use source control? + 1 (We used VSS, shoulda used Subversion - we had some VSS hiccups that cost us time, although, last time I checked Subversion had some problems with ASP.Net projects, too.)
  2. Can you make a build in one step? +1 (no automated script, just hit build in VS)
  3. Do you make daily builds? +1 (Not too applicable to our little web app, but we essentially did this)
  4. Do you have a bug database? 0
  5. Do you fix bugs before writing new code? 0 (didn't use a bug database and didn't really pound on the code)
  6. Do you have an up-to-date schedule? +1 (used Joel's format)
  7. Do you have a spec? +1 (used Joel's format)
  8. Do programmers have quiet working conditions? +1 (got the Team Palace)
  9. Do you use the best tools money can buy? +1 (Good dev machines, latest software & 3rd party components)
  10. Do you have testers? 0
  11. Do new candidates write code during their interview? +1 (I instigated this one)
  12. Do you do hallway usability testing? 0 (shoulda, woulda, coulda)

Our Total: 8 - Not great.

We really should have been using a bug database, and I should have made the declaration that we need to find and fix bugs before writing new code. The project was a bit of a whirlwind, and it felt a little out of control at times, but that's all the more reason to try to confine the chaos.

The project could have supported a tester - we even had a young (read: cheap) guy that was light on work who could have done the job. He left for a vacation to his homeland - Nepal - early on though, and wasn't around for most of the project.

We easily could have done some usability testing - it was even in the original scope. Our usability lead left the project early on for maternity leave, and that loose end just didn't get tied up.

We did have a great team room though, and that was really the hallmark of this project. It was a big breakthrough for us because it was the first time a development team had requested their own room, and it caused some ripples throughout the office which will hopefully start to bring about change in how developers are perceived.

We overcame some early team friction, and in the end we jelled very well. I feel like I've made some new friends during this project who were just coworkers before.

We had a good up-to-date schedule thanks to Joel's spreadsheet (I've even been asked to give a brown-bag presentation over lunch to our division), but the original estimate wasn't exactly realistic. The problem always boils down to not knowing enough about the scope of the work at the time we submit a bid for the project. We aren't given a cushy business development budget to really nail down a scope prior to bidding on it, and frankly, our client likely would have been put-off by us if we tried. When I originally priced the project, I came up with $92K. The business analyst who knew the customer well balked at that figure - unfortunately, he is a business systems analyst and doesn't know by experience what goes into a software project - so I cut the cost down to $62K by making some major assumptions. In the end, the project cost about $75K, and we were able to ask for the extra $13K from the client due to out of scope requests; it remains to be seen if they'll actually pay us for it though. I now regret having bent to the pressure to reduce the original estimate. I think it would have been spot-on for a quality web site that was well debugged. Instead, we produced a fast and cheap application that sacrificed accuracy.

We had a problem with entangling priorities. I was being pulled in two different directions by critical dates on this and my other project. I don't think its realistic to expect to focus on just one project in my line of work, but I can't avoid saying that dividing focus does reduce quality.

The spec documents were a big hit - we wrote them with a sense of humor that was a welcome change for our readers. The clients and the project manager all appreciated the specs, and it was obvious that they actually read them in entirety.

The end product is finished, and I'm glad to be moving on. Getting closure is one of the benefits of a quick job, and if you've ever been unfortunate enough to work on a job that drags out indefinitely with constant scope changes and no schedule, I'm sure you appreciate closure, too!

Thanks for all who have read and commented on this series. I hope it has been an entertaining read - it was fun to write. I'll be switching back to a more technical style for a while, but I may revisit this novel-style periodically.