Magpie Developers & Their Opposites

October 29, 2020
Ryan Findley, Principal
Philadelphia, PA
“I’ve often thought that software developers were akin to Magpies, birds notorious for stealing shiny items to decorate their complex nests. Like Magpies, software developers are unusually smart and curious creatures, almost by definition. But we are too easily distracted by shiny new toys and playthings.”

Jeff Atwood, co-founder of Stack Overflow

I think many developers ignore this observation because “Taking this reasoning to its reduction ad absurdum would mean picking Java and then trying to implement a website without using anything else at all. That would be crazy. You need some means to add things to your toolbox.”

”It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it.” —Dan McKinley

We all know someone who jumped from tool to tool and eventually settled somewhere. Whether it’s Java, PHP, Cobol, or (in the case of Neomind) Ruby, finding tools you love to solve a particular problem and sticking with them can lead to a depth of understanding familiarity that completely changes the game. I believe this happens to developers when they get tired of the endless churn of new technologies, and as they start to care more about maintainability.

I’m not arguing that Ruby on Rails is the best tool for every job or that it’s so good everyone should stop inventing new things. On the contrary, I love that people are always experimenting, and I love playing with their experiments. But it would be unprofessional and irresponsible to use every shiny new thing on the types of long-lived assets most people are building.

Why is it unprofessional and irresponsible to use shiny new technology?

Many new tools and frameworks implement sweeping changes after their initial versions, making the upgrade path virtually a rewrite from scratch. A new fad replaces others and fizzles out. Marketing sites, special seasonal initiatives, or one-off applications that serve a limited need have lifespans measured in months. On projects like these, longevity and maintainability don’t play a role in the decision-making process, and developers are free to experiment with whatever new tech they choose.

Most of the projects we see have lifespans measured in years, and yet what is the decision-making process for choosing the platform? Projects governed by the tech-fashion-trend of the day.

unlambda meme

Using new/unproven technologies on projects like these would be an irresponsible waste of other people’s money. Failing to consider the lifespan and maintenance needs of the project when choosing a framework would be nothing short of unprofessional (and as someone who uses Zoolander memes in his blogposts, I know a thing or two about professionalism). Yet, many developers make their technology choices purely from what will be the most fun for them. Bored developers find a little “Resume Driven Development” hard to resist.

Even worse, many managers allow this kind of decision-making to “keep the developers happy” and hopefully reduce turnover costs. Many times, the developers only stay a little longer, and there’s a trail of disjointed, unrelated, hard-to-maintain experiments left in their wake.

Choosing a framework whose longevity and maturity reflect your application’s likely lifespan and needs is an important consideration. There are no guarantees, but choosing an immature platform with a small or disengaged community can be a costly, unprofessional mistake.

“Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.” Also Dan McKinley.

Recent Blog Posts

March 11, 2020
Cleaning up other people’s messes is a growth industry
People are increasingly choosing not to start from a blank slate, but to start from something good (or, in some cases, something just okay, or even bad) and make it into something great. 
March 11, 2020
"This code is terrible, we have to start over"
One crucial-yet-rare skill needed to prevent a codebase spiraling into “legacy” status is developer empathy.
March 11, 2020
Have confidence in your critical applications
​Developed by a moon-lighter, built by a team that's no longer involved, or stewarding open-source contributions, get confidence in your application.
April 14, 2020
COVID-19 Announcement for Existing and Prospective Clients
Please do not hesitate to reach out to me directly if you have any questions, concerns, or ideas for how to make this sudden and unexpected transition to remote work go more smoothly for your team.