Part 1 | Part 2 | Part 3 | Part 4

Wow, where to start…

Can I just start and end with “never trust a PM named Stan?”

This has been the toughest post to write.  I’ve started and stopped a few times, some of it good, most of it bad.  The fact is, I did learn some things from this project, some of it new, and some of it stuff I already knew and this just reinforced my already-held beliefs.

Honestly, while I thought the PM had a clue at the beginning of the project, by the end of the project, my feelings about PMs were reinforced.  Of course, maybe my idea of what a PM is supposed to do is wrong .  Maybe I just haven’t had the opportunity to work with a really good one yet.  The PM on my current project seems to have his act together, but only time will tell.

Before I get to what I learned, I want to list some of the mistakes I made:

- I should have gone with my gut feeling at the beginning of the project.  Unfortunately, money talks and I needed the gig.  if I hadn’t taken the gig, who knows what I’d be writing about right now.

- I should not have been so quick to assume the tech lead role.  When I interviewed with Dave D., the recommendation he gave to the HR people is that I needed to work on a project or two before assuming a tech lead role.  He said this for a reason.  It would have given me the opportunity to learn how the consulting company did things and fully understand their process.  He was pretty open with me during and after the project about how things should NOT have played out the way they did.  I have led teams before and I’ve done a good job.  My mistake was thinking that I had all the answers for this project and could easily fix the problems.  Of course, I’m not sure anyone could have saved this project…but it would have been nice to see how someone like Dave or James would have dealt with it.

- when I did take over, I should have gotten clarification on my specific duties AND requested an experienced tech lead at the company as a mentor.  By the time I got the clarification, it was almost too late to do anything about it.  For example, I was supposed to lead all UATs (user acceptance tests), but the PM set the precedent and I actually only led one of them.  A mentor would have helped as well, for what I hope are obvious reasons.

- I took shortcuts that ended up costing us.  As I mentioned, early on we were under the gun to produce results so instead of taking the wireframes and re-developing them, we simply did a cut-and-paste job and then renamed controls.  The unfortunate side-affect that really screwed us was all the nasty inline styles and javascript.  We *should* have taken the time to strip that stuff out when we first developed a page.  Instead, in the interest of time, we simply kept it all in and ended up having to hack around a lot of it later in the project. 

- I should not have allowed any development to take place as long as one-line requirements were coming in.  I’m not sure how far this would have gotten me, but I should have been more hardcore about this.

- I should have approached testing differently and setup something like Watir or Selenium.  The UI testing was pretty random and reproducing issues was really tough.

I think the biggest thing I’ve learned / re-learned is DO NOT BE A HERO.  There’s more to life than work.  If a project is doomed to fail as I believe this one was, no amount of overnighters or long weekends is gonna save it.  I look back over those months and all those long hours and I wish I had some of them back.  Hell, I wasn’t even getting paid for most of the extra hours I worked.  Yes, it did seem like the right thing to do at the time, so there’s not much to do about it.  I was coming off a couple months on the bench and I wanted to prove (mostly to myself) that I could do it.

I’m happy with my selection of NHibernate and NHibernateRepository though.  I can’t count the hours we saved by not having to write stored procs and wrappers for those stored procs.  I’m also happy with the wiki and issue trackers I setup for the team to use.  These proved to be invaluable throughout the project.  Of course, the issue tracker became less useful once the PM accidentally wiped the entire database, but luckily that was in the last week of the project.

I am a firm believer in continuous integration and having good test coverage, but I don’t necessarily believe in putting a stake in the ground and saying “we WILL have X% coverage”.  Our goal was 95% coverage (mandated by the consulting firm), but that was a tough number to meet given how loose the requirements were and how often they changed.

There were mistakes made by others during the project, but I’m not sure they really matter anymore and I hesitate to bring them up now.  After saying that, I will talk about a couple of issues…In my opinion, the PM cultivated an inappropriate relationship with the client that essentially put him squarely on the clients’ side.  The CEO of the consulting firm I was working for was also an investor in the client.  Right or wrong, I didn’t agree with it and I think it cost us.  When issues were brought up to management, it was brushed aside.  As I recently told someone in an email, the company could talk the talk, but they almost never walked the walk while I was there. 

Just think about it…if they had supported the team and listened to us, I could be writing an entirely different series of posts.