Agile. Scrum. Waterfall. Test-Driven Development. Extreme Programming. All methodologies for making software that actually work. Some debatably better than others. There is one development methodology that is guaranteed to fail, and cost you dearly in the process:
Resume Driven Development (RDD)
It’s simple. In RDD, one makes decisions to enhance their own resume as the highest priority and at the expense of institutional learning, compatibility, and predictable engineering outcomes.
You can spot Resume Driven Development by the results:
A slower than expected development cadence. No one wants to guess how long a new feature will take, mainly because they don’t know the new tech well enough to guess.
A tech stack that reads like “Top Programming Languages to Learn in 2021” and “The 20 Highest Paying Tech Skills to Have in the US” had a love child.
New features are shallow and incomplete. You’ll hear lots of explanations like, “We can’t get that working the way we want until we move there old feature over to the new database.”
So what do you do to prevent Resume Driven Development?
It’s hard. Back to “Top Programming Languages” and “Highest Paying Tech Skills”. Developers have a personal incentive to include new technologies in your product stack. Sometimes new is a lot better, and worth the investment. So what do you do to prevent RDD?
Have standards and understand why you have them. Often, the reason why you have a standard is more important than the standard. Make sure you explain the non-technical reasons for the standard.
Avoid using superlatives like better, superior, faster, cheaper in the reasoning as these are usually relative advantages that will change over time. Focus on why this technology matters to our team. Training, external tools, user workflows, and business enablement (our biggest customer uses it) are all really important details. Make sure you clearly lay out what the standard is and why you have it.
Most importantly, insist on sticking to the standard until it is clear the standard needs to chage.
Example: Why we use PostgreSQL (and do not allow other databases) in our product:
1. It is easy to find developers and DevOps engineers who know Postgres. Because we have a single database, it is easier to train new team members.
2. By using a single, widely adopted database, we make it possible for non-developers to use standard business intelligence tools. This allows our team to focus on building product features instead of re-inventing business intelligence software features.
3. Because Postgres is widely supported by languages, frameworks, and cloud vendors, we have flexibility in future tool choices.
(By the way, ten years ago, we would not have been able to say any of the above about Postgres. Things do change.)
OK, so how do you know when change is needed?
Tolkein (and later PEP-8) pointed out that a “foolish consistency is the hobgoblin of feeble minds.” Yes, you do benefit from stability and a predictable development cadence. Sometimes, the new hotness is really that much better, and it is worth slowing time to integrate it. What do you do when a developer recommends adding something new to the stack, or changing to something new?
First, see if there’s more to it than “faster”, “better”, “cheaper”.
Everything can be spun to be better and faster. Cheaper is often simply not. Savings on licenses and hosting can be quickly lost when you have to hire an additional person who knows the new tool.
So, what’s left?
Big stuff like increasing sales, enabling new business, reducing risk, lowering maintenance costs, reducing code, and improving reliability. All things that really matter. All things that are worth investing in. A lot more than MongoDB being faster than Postgres.