Adam Lenda: Always Choose Consistently Bad Over Inconsistently Good
Yesterday, I was listening to an older episode of the SQL Data Partners podcast in which the guest - Adam Lenda - phrased something in a way that I've never quite heard it before; and, it stopped me in my tracks. The episode was all about accumulating and dealing with technical debt as a team in long-term projects. Several times during the episode, he underscored the point: "Always choose consistently bad over inconsistently good". Meaning, it's easier for a team to participate in, understand, evolve, and "fix" a consistently bad set of architectural patterns than it is to fix a patch-work of different solutions.
.... And then from those two points I kind of go to a third point, but before that, I want to hit these three maxims. Which is to say, always choose consistently bad over inconsistently good, because that's going to help you be more efficient, and with efficiency comes the opportunity to refactor that consistent problem, and it's much easier to solve a consistent problem than an inconsistent problem. — Adam Lenda
Sweet chickens, I feel this point so hard! And, I absolutely love the way he positions it, attributing adverse outcomes to seemingly "good" ideas. Because, it reminds us that everything is contextual. Nothing is good or bad in a vacuum. Much like I discussed in Episode 12 of the Working Code Podcast, there are no "right tools for the job" - there is only the right tool for the job, for the team, for the skillset, for the priorities, and for the customer at that specific moment in time. Because, what is considered right in one context can certainly be wrong in a different context.
When I reflect on my time at InVision, the things that have slowed my team down the most are when an engineer implemented a radically new approach under the guise of "performance". This is why the React code, running within our AngularJS application, is sitting there rotting. This is why I've spent so much time (and opportunity cost) merging microservices back into the monolith. Because if I can just get things back to "consistently bad", then maybe I can really start to improve them.
At the very end of the show, Adam Lenda answered a question about the "best advice he'd ever received". And while this is completely unrelated to the main topic, it's so good that I wanted to share it here as well:
Again, I gotta go back to Mark Spinek. Very influential point in my career, I guess, but he said, "be a developer who doesn't need a project manager." And I think that there's a lot of depth there, ... a great developer keeps their eye on the ROI [without needing] to have someone check behind you to make sure you're getting your stuff done. These are the things that make you leadership material. These are the things that make you worth more than your peers, to give you the greater opportunities to go work on more interesting projects. Like if you're bored where you're at, try and solve that problem and see if you can't find yourself in some more interesting positions because of it.
1000% yes! The only reason that I've been able to be so productive over the last year, having lost both my EM (Engineer Manager) and my PM (Product Manager), is that I try to be a developer who doesn't need a manager. I try to proactively solve problems; I try to keep in touch with our CFT (Customer Facing Team); I try to keep in touch with the customers; and, I try to develop a holistic sense of where value can be added. I am never bored. And, I always have a list of things I want to build for our customers.
Anyway, I recommend listening to the episode. It was a really interesting discussion. And, the topic of technical debt and team dynamics is always timely and it's always relevant.
Reader Comments
Thanks Ben.
I would take the maxim a bit further:
Always choose consistency.
As you say, whether it is consistently good or bad is contextual. And, if it is judged to be consistently good it will be easy to reason about. If it is judged to be consistently bad it will be easier to fix when it comes time to do so.
Thanks,
Murray
@Murray,
The older I get, the more I tend to agree with what you're saying. In particular, I often think back to the old adage:
And, the more experience I have, the more I am totally comfortable with this concept. If all you have is a hammer, and you're really good at using hammers, and anything else other than a hammer would make you much less efficient, then I'm OK treating everything like a nail. Because, that's how you get stuff done.