Pond’s Thirteenth Law: Change Won’t Be Cheaper Tomorrow
Herewith, a discussion of the emergence of Pond’s Thirteenth Law (if you need to catch up, here are Laws One through Ten, Eleven, and Twelve, as well as three ruminations on the implications of Pond’s Seventh Law)..
One of the great things about my job is that I get to spend an embarrassing amount of time having conversations with really smart people. The next couple of posts I’ve got planned are the product of conversations I’ve either had or eavesdropped on (via email).
My primary project these days is the SIPA system I’ve discussed in this space several times before. My colleague Gerardo Saca van der Meden (who is going to be a superstar in this business, mark my words) and I spent the weekend thrashing through our complementary-but-not-entirely-aligned views of some design changes which we’ll be including in our next version.
At one point (when he erroneously thought he might lose our thoroughly professional “argument”), Saca wondered if we couldn’t possibly table the changes I was suggesting until after our pending release, in favor of spending our remaining cycles for this release building new features.
This is an interesting balancing act to contemplate, and my purpose here is not to suggest that there’s only one right answer to this question. Rather, when making a decision like this – when to embark on a redesign, refactoring, etc. – it’s important to remember Pond’s brand-new Thirteenth Law:
Whatever change you’re contemplating, it won’t be any cheaper tomorrow
My primary concern with Saca’s suggestion was that it increased the scope-of-work of our redesign effort – the new features we build between now and then would have to be rebuilt in light of the redesign. This is neither good nor bad, it just is, and it needs to be given its due weight in the decision-making process. Is getting the features to market quickly worth the cost of the rework?
As luck (and Saca’s mad skillz) would have it, no redesign is necessary. We can effectively meet our requirements with the design we had, a statement we can make with much higher confidence than we could before the exercise.
If we had needed to make the change, I would’ve put in overtime to make deadline. That was my offer to Saca to ease his pain-of-entry into contemplating the possibility of a major mid-course change. If you’re the techie in this conversation rather then the dev lead, remember that your lead is going to have to explain what looks like a mistake to the rest of the world. If you’re going to put him through that, help him out – give him an above-and-beyond commitment that he can use to help balance the equation.
It’s a rare dev lead who will tolerate (never mind participate enthusiastically in) this sort of mid-course soul-searching (and if you ever do undertake such an exercise, I suggest you set a tight deadline on it and stick to it, which we did). When a senior team member is questioning a design decision, the dev lead’s reaction can color perceptions and team relations for a long time, either for the good or for the bad.
So, in such situations, be open-minded, be flexible, and above all be efficient (this is a situation that calls for a quick decision; you want to make sure you’re performing the most cogent possible analysis). If you can grit your teeth and get through the interruption, you’ll end up with more confidence in the course you ultimately select, as well as team members who know their opinions are valued, even when they’re not valid.
With apologies to Don Henley, senior techies who’ve been burned by bad leadership in the past will walk on their tongues over broken glass to get next to a dev lead like that.
Do you have any stories about good dev leads? Or even bad ones? Share them here..
-wp
this copyrighted material was originally posted at https://blogs.technet.com/wardpond.
the author and his employer are pleased to provide this content for you at that site, and via rss, free of charge and without advertising.
the author welcomes and appreciates links to and citations of his work. however, if you are viewing the full text of this article at any other website, be aware that its author does not endorse and is not compensated by any advertising or access fees you may be subjected to outside the original web and rss sites