Lessons Learned: part 2/5 – From bad to worse

06 Jul
by mjeaton, posted in Uncategorized   |  2 Comments

Part 1

Note: I know this is a long one, but IMO, it’s worth it.  Without actually quoting emails and IM transcripts, it’s tough to illustrate the insanity. :-)

As I mentioned in part 1, after leaving the first meeting, I truly didn’t feel like signing the contract.  The client wanted too much stuff within a very short fixed period of time, and to be honest, I didn’t get a warm and fuzzy feeling about the tech lead during that meeting.  He said some things that sent up some red flags, but at the time, I blew them off as different people do different things.  :-)  After all, I was pretty happy to be sitting back as “just another developer” on this project, so I gave him the benefit of the doubt.  BTW, One of the early “red flags” was his insistence that the 3 of us (him, me and John) would “share” the tech lead responsibilities.

Before I forget, I have a quick addendum to part 1 — during the 2 weeks of “Plan and Define”, the tech lead also developed several user stories.

I realized pretty quickly that the tech lead really didn’t have the depth and breadth of experience that John and I had (more red flags – again, based on things he said), so I volunteered to setup our development server (which would run our CI).  As luck would have it (BTW, that was sarcasm), instead of dedicated hardware, the team was allocated a VMWare virtual machine configured to our liking.  After some back-and-forth with the admin, we ended up with a vm that had 768mb of RAM, 10GB of disk space that was running Windows XP with sp2.  I installed CC.NET, Subversion, Screwturn Wiki (which ROCKS btw), Sql Server 2005 Express, NUnit and NCover.

 By this time we were a few days into the project and knew enough about the problem space to decide on using ASP.NET/C#/SQL Server 2005.  The tech lead was busy doing whatever it was he did in those early days and John and I were spending our time working out how we were going to actually get things done.  A UI designer joined the project and was assisting the tech lead and the PM in client meetings to start laying out the look and feel of the application.  

John, as it happened, had experience with Rocky Lhotka’s CSLA and I’ve always used something a bit less heavy.  During this time, we both wrote up short papers that discussed our desired approach.  The fact was, we had a ton of work to do and very little time to do it.  We had to decide on an architecture and we had to do it quickly.  The tech lead really didn’t have much to contribute during this time (another red flag) but he did have the final say, so while John pushed CSLA and the UIP, I was pushing relatively light-weight custom objects in the middle tier along with NHibernate in the data tier.  Due to my excellent skills of persuasion (more sarcasm), we ended up going with an entity model using NHibernate.  The middle tier consisted of “manager” classes that would accept and return instances/collections of entity objects.  I may blog about this approach in the future because as far as I’m concerned, it worked out pretty well.  Granted, by the end of the project, I had learned some lessons, and thanks to Will discovered better ways to do some things.

I should mention that because of the red flags I saw early on and because I knew we would be bringing on more developers throughout the project, I wanted whatever we chose to be extremely easy to use and intuitive.  In my opinion, simple entities and manager classes met those goals.  Also, since we were going to be using NHibernate, we eliminated stored procedures from the equation.  Instead of calling NHibernate directly, part of my plan was to use Dave D.’s awesome NHibernateRepository.  Again, we needed simple and intuitive.

One of the things we did decide in those early days was that John didn’t mind doing UI work and I really preferred to do the middle tier/back-end work.  We came up with this:

  • Mike – mostly back-end
  • John – mostly UI
  • Both of us – middle-tier

 Ok, one thing you’ve got to understand is that based on my interview, I had pretty high expectations of those around me, especially the tech lead.  Before I talk about him too much, here is an email that was sent to the team within the first couple weeks of the project.  Keep in mind that John and I were both “.NET Developers” at the start of the project.

Responsibilities:

PM/BA
* Responsible for overall delivery of the project

* Manage IRP, Truth Plan, Project Log, Change Requests

* Regularly communicate project status to stakeholders

* Responsible for establishing project Cadence (scrums, status, UATs, etc)

* Work w/ SME to develop Use Case documents to be passed to developers.

Tech Lead / .NET Developer

* Responsible for overall _technical_ delivery of the project

* Break User Stories into tasks

* Work with other developers to estimate & re-estimate tasks

* Ensure that build is ready on a weekly basis for Monday UAT.

* Responsible for developing awesome test driven code.

.NET Developer

* Responsible for developing awesome test driven code.

 Around a week into the project, we had determined the overall architecture, setup the CI / dev server and started daily scrums.  We still only had a rough idea of what we were supposed to be working on, so at the behest of the PM, John and I blindly jumped into working on the application.  The only thing we had that represented any kind of UI was a Flash demo the client created.  The wireframes from the UI guy weren’t in our hands yet, so John started developing some pages based on the Flash demo and a very, very rough use case while I started doing some database design based on the limited info that I had.

Hindsight is 20/20.  All the things we were “rushing” to get done were core to the application, but no one seemed to care at that point.

Around the second week things started to go down hill pretty quickly.  While the team as a whole decided this should be a web-based project, the tech lead wasn’t as sure as the rest of us.  The fact is, the UI designer had “wowed” the client with some great looking screens and the majority of us felt that since it had a very “webby” look and feel, we’d be hard pressed to re-create that same look and feel using WinForms.  In fact, the UI designer was providing wireframes as HTML!

During a Friday scrum, the tech lead brought up WinForms and really pushed hard for us to switch gears.  We decided that on the following Monday, I would do a WebEx demo to show how easy it was to take a wireframe and create a working page from it.  The BEST quote from that Friday scrum came from the tech lead:

“But, HTML is so confusing with all that punctuation”

I am 100% serious.  My jaw dropped when he said that!  For those not in software development — basically he was admitting that he had ZERO experience in web development.  It also turns out he had ZERO database experience and very little Windows development.  Ok….so my question at the time was “WHO THE HELL INTERVIEWED THIS GUY?”  It certainly wasn’t Dave. :-)

Anyone that knows me knows that I can get emotional, but I did my best to keep my cool.  It really helped that I was actually on-site with another client during this scrum.  Anyway, after he said that, my “WTF!” meter jumped through the roof.  After the team picked themselves up from the floor, we still pushed ahead with me doing a WebEx demo on that Monday.  The edict was for him to STAND DOWN on the WinForms until the meeting on Monday.

Over that weekend, the tech lead emailed everyone and stated in no uncertain terms that we WOULD be proceeding with WinForms and that he already re-created all of our ASP.NET work.  Needless to say, the PM, John and I fired off several emails, some heated, to the tech lead.  At some point, one of us CC’d the Managing Director to get him involved.

On Monday, we convened for my demo, but that turned into a FOUR HOUR conference call from hell.  The tech lead would NOT budge and the rest of the team (the PM, me, the UI guy and John) kept trying to convince him that we could be extremely productive writing ASP.NET and that based on the clients desire to have something visually stunning, we’d be crazy to go with WinForms (not that it can’t be done, but we’d have to invest time in figuring it all out and most likely purchasing 3rd party components).  He continued down the road that HTML was too hard and that we should be “dragging and dropping” everything.  I found it very difficult to keep my cool in this meeting but was able to stop myself from calling this guy was he was: a total idiot.

Finally….FINALLY, after 4 hours of him digging his heels in and the rest of team unwilling to concede, the managing director stepped in and made the decision for us: the app would be web-based!  Believe it or not, the tech lead CONTINUED telling us we were wrong!!!  He actually said that the only place he’d be comfortable given his (lack of) experience was doing the UI but only if it was WinForms!  I tried to explain how the entity classes were auto-gen’d by CodeSmith so he would be writing very specific business-related code.  I also tried to boost him up a bit by telling him how simple HTML was and that he’d catch on really quickly.  He was not convinced.  In fact, in the following days, he continued to IM me telling me we were wrong and that there was NO way we’d complete the app if we used ASP.NET.

It was only 2 weeks into a 6 month project and my descent into hell had just started. :-)   Part 3 coming soon.

2 Responses to Lessons Learned: part 2/5 – From bad to worse

  1. Dave Donaldson

    WoW, those are some interesting details. Looking forward to the rest of the series.

  2. 岡崎市 不動産

    応援しています、頑張って下さい。
    岡崎市 不動産