We had a flood in my house when I was in Europe last month.. Apparently the toilet overflowed in the upstairs bathroom when my grown son was here alone (apparently :-)) and it destroyed the upstairs bathroom, the hall (which means replacing all the hardwood on the main floor) and then it flowed to the basement and destroyed drywall all around our recently finished basement and destroyed all the laminate flooring. Ouch !! Glad I wasn’t here. Thanks for insurance (until my renewal next year).
So my office is now in our bedroom and I have two guys working right next to me rebuilding our bathrom – including this plumber “J”.
“J” asked me what I do – and as we were talking it occurred to me that there are a lot similarities to what he’s doing and what we do. And it all wraps around CLIENTS !! and CHANGES ….
In this case the bathroom has been stripped right to the studs and subfloor (the wife wanted a FEW changes at the same time). So they are building from scratch – just like a new application from scratch. We are making subtle changes as we go along but no problem at this point. But it occured to me that their worst nightmare is when the change is asked for AFTER they’ve finished the final touch-ups or months or years down the line. The client wants a change that means cutting things open that are working just fine. Familiar ? Aaaaggghhh.
This re-enforces in me the things I ALWAYS try to do before doing a project:
1. I determine whether this business process SO stable that it won’t change for years (if ever)? That is NEVER a sure thing, but I try to determne that up front.
2. I make sure I define EXACTLY what they NEED – not what they WANT.
3. I drag out the development as long as possible (not increasing the price just dragging out the delivery time) so they have as much time as possible to think about what they REALLY need before we do the “final touch-ups” and go into Production.
4. BUT I make sure not to drag it out TOO long because it is possible the client will lose interest (short-attention span) or worse something will change in the business structure (firings, promotions etc.) and the project will get chopped along with a large part of mycompensation.
5. NOT having a detailed contract is a good thing when developing the initial application and probably a BAD thing when doing revisions after the fact.
Remember – once you go into Production it gets much harder not just to make changes but especially to implement them and test them without a major cock-up (as Simon would say) destroying all credibility for yourself and the application.
All of this means developing a good relationship with your clients – and of course it gets easier for the second, and third, etc. projects.
So “J” the Plumber and we developers are in fact kindred spirits and we didn’t even know it.