Being a professional developer means following standards, standards that are set by smart people (smarter than me at least) and when you start to break those standards will wrong. I know this! However this past Friday I broke many a rule and failed, because thought I knew better this one time. So this post is a retrospective of what went wrong, so that I never forget again.
The project is a fairly complex backend system for a special mobile device, and when I mean complex I mean in size and scope. We have VB.NET, C#, Java, JavaScript and a ton of inline SQL! The work itself is done by three different companies with three different agreements, policies and methodologies! That sounds like a recipe for disaster but it isn’t – we have exceeded every goal! That is until Friday.
On Friday we get told the customer is coming at 9am on Monday for a demo! We have 8 hours to get ready for it! The software is in a state between alpha and beta and we have known issues that need resolving by the demo. So we worked hard and make great headway until about 3pm. Then we hit an issue everyone in the room thought was on the mobile device. The first problem is the mobile dev company isn’t onsite today, so we are really guessing at the issue.
We start experimenting at fixes, pushing 7 builds to QA in an hour (in reality we are lucky if get 5 build to QA in a day). At the same time we are adding bug fixes and tweaks for other items too! Then the answer comes in the mobile device developer – they breaking because their expectation of the spec is not the same as ours. More fixes and adjustments and then the server just stops.
At this point, I am looking at my watch, I have a two year old son sitting at school and it is almost time to pick him up. tick tock. Being a single parent means I MUST leave and soon. The mobile guys have gone offline completely. Another dev from the third company is needing to go and propose (she said yes 
)! We are all rushing, skipping testing, skipping building locally before checkins… I even checked code in without comments! NOTHING, no matter what I try it keeps breaking, tick tock, same error every time, tick tock, I can’t find it, tick tock, the PM is looking worried and looking at me to solve it, tick tock. OUT OF TIME.
I apologise and leave, feeling crap. I failed. I let a client down.
Saturday, I sit down to dig into the code. Now without the time pressure, and I read the stack trace properly for the first time (stopped assuming what it was saying as I was when I was rushed) and quickly found the issue and resolved it. One code checkin (built first locally, with check in comment, and assigned to work items etc…) and it is working. The test client works too!
In retrospect what should I have done is simple: We knew there is a demo, it was late notice but we had chance to choose what to show to the customer. We should’ve set a cut off time after lunch for fixes and changes and then just not included broken things in the demo. Rather have taken that after lunch time and made sure the demo showed 80% and that 80% worked 100% than rush to get 100% to show and in the end break it all.
I should’ve also stepped back earlier and done something else for a second – get coffee or something. Just to clear my mind and calm myself. Stepping back always helps, just think of how many times you ask someone for help and in explaining it you solve it yourself.
Finally skipping the standards that make us professional leads to disaster and I should’ve made sure the following standards were kept!
- make sure it builds locally before checkin
- check in comments
- assign each checkin to a work item
- test locally before checkin
- If we have a deadline, then we get everyone in the room to make it happen. We win and lose as a team.
- The more detailed the spec is, the better for everyone.
- Do one thing per checkin (keep those checkins small and focused)
Monday has come and gone, the customer loves it and the demo was great. We succeeded. It required sacrifice from the team of some of their weekend, a sacrifice that if we have acted more professionally and clear headed could’ve been avoided. This doesn’t happen often to me, as I am often surrounded by professionals and when one of us loses it the rest helps push that one back into place, so this post really is a reminder why we do that for each other and what others can learn.
Management is doing things right; leadership is doing the right things – Peter Drucker