The Never Ending Epidemic of Resume Driven Development

As a consultant, there tends to be a bias in the types of projects I get pulled into.

Many involve filling in the gap in terms of expertise. Others involve reverse engineering previous systems and infrastructure and still, others are focused on providing advice.

But one of the categories of projects that show up is fixing key-person dependency issues. But there is a sub-category within this style of project.

That is simplifying resume-driven development projects. 

These types of development projects tend to attract the need of a consultant post the individual leaves because often the person who did develop it was far more willing to spend extra time to make it work. Now, this may no longer be viable.

In some cases, a replacement hire may have not even been onboarded prior to the previous engineer or director leaving. Meaning there was a few months between when the solution was implemented and a new person had to take it over.

In this article, I wanted to discuss RDD, why it happens as well as discuss some of the pros and cons.

What Is Resume Driven Development

Source

There are a lot of X-driven development styles( e.g. test driven development). One of them is known as resume-driven development.

If you haven’t heard of this concept, it’s kind of what it sounds like. Instead of building solutions that you need. You build a solution that sounds good on your resume that often relies on trending technologies.