Obituaries are dead. How to announce the demise of tech with empathy

Image Credit: @dogmodog

Proclamations a-la “PHP is dead” and “Stop using Next.js” are littering Medium. My reaction to one of those is almost always the same: there is no merit to it and the author is just an amateur, who hasn’t been long enough to be taken seriously.

Just because there are perceived better alternatives or some dubious stats you find on the internet back your claim, you can’t assume that something is dead. There are people that continue maintaining swaths of the web and enterprise software that is built with “obsolete” technology. A programming language that’s been around since 1972 is sometimes a better fit for powering Mars rovers than some hyped new language without enough time in the wild to show its weaknesses.

A good developer knows that success of the software is almost entirely dependent on the choice of tools. Just because someone thinks that X is better than Y in whatever narrow context they are working on, does not entitle them to proclaim that everyone should immediately cease and desist using Y. Ultimately, it’s all about understanding the requirements, considering the implications and weighing trade-offs.

Instead of wasting your time and boring your readers with yet another tech obituary, consider being more mindful and helpful with one of these formats.

Article Formats

Deep Dive Article

Did you experiment with some new tech and found it to be the right fit for the job, share your experiences:

• What are some underlying principles that the tool is based upon? What were the motivations that the authors were pursuing?
• What dependencies does the tool have, and what implications might they have on various aspects of software development (DevEx, CI/CD, testability, observability etc)
• What are some use cases that this tool would be a good fit for?
• How do you envision this tool’s future: any suggestions on how to improve it, any background on who are behind this tool and how will they ensure that they tool is not deprecated half a year later?
• Is this tool production ready? Is it tested and testable in integration? Does the repository hygiene look satisfying to you?
• What are some of the preceding and alternative tools, and why would you recommend this tool over those?

Pros and Cons Article

No matter how wonderful the tool you are trying to sell to others as the panacea to their worries, everything comes with trade-offs. If you don’t have any concerns about the approach or tool you are recommending, perhaps you should hold off writing an article, as you don’t really understand the subject matter well enough. Without enough information you might be setting someone off on a wrong path.

• Assist others in their decision-making process by listing advantages and disadvantages of various tools aiming to solve the same problem
• Prepare others for problems they might encounter when choosing one over the other
• Provide links to other resources that helped you understand the tools better and make your own educated decision
• Show snippets of code to demonstrate how implementation differs, and why one is more beneficial or easier to adopt than the other

Reflection Article

If you really wish some tool dead, because it wasted your time and wasn’t suitable for the job, don’t denigrate people, who have taken time out of their schedule to build and support the tool. Instead try and reflect on your own experience, and understand where you went wrong with the decision:

• How did you evaluate the tool before using it?
• Was it your specific use case that this tool failed to address? Why do you think that is and what should others watch out for?
• Was the documentation misleading and how would you improve it to prevent others from repeating your mistake?
• Was lack of support or communication from the authors a factor in your inability to take full advantage of the tool? Would this tool be more reliable if there were enough monetary and coding support from the community to boost the authors’ motivation?
• If you were to author a similar tool, which decisions would you make differently, and what do you think it would take to refactor/enhance the tool to be more usable.

Tutorial

If you think that A is better than B, and convinced that everyone should make a switch, don’t tell them to Stop using B without understanding what that would entail in practical terms. Instead, if you had to follow your own advice, what steps would you take:

• What is the easiest way to switch from B to A? Do you have any tips and shortcuts?
• Can you provide step-by-step instructions and how-to’s?
• How can someone estimate the amount of work that would go into refactoring an existing code base?
• How can someone estimate the benefits of switching and calculate the return on investment? What are some KPIs that could be taken into consideration?
• How would you sell the need to switch to your management? What are some longer term benefits? Will it improve testability or observability? Will it improve DevEx and make the team more efficient?
• Which resources are there should someone encounter problems during the migration (documentation, forums, articles etc)?

Mindful Headlines

Everything starts with a headline, so next time you sit down to write, read your headline and ask yourself — is this helpful to anyone?

Rewrite your headline to be helpful, and the rest will follow.

X is dead

• 10 reasons why the adoption of X is declining
• X is dying — how can you prepare of its demise
• What can we do to keep X alive
• Why I am sad to see X go
• The world would be a safer place without X
• How to prevent the X disaster from happening again
• X: the good, the bad and the ugly

Stop using X. Use Y instead

• How X compares to Y and why should you care
• Accessing the benefits of switching from X to Y
• How switching from X to Y made me happier/more productive
• A roadmap for sunsetting X
• Improve testability/observability/dev usability/accessibility by switching to Y
• 10 reasons to switch from X to Y

You can also reframe the argument and instead of focusing on specific tools, use your bad experiences to formulate what an ideal choice should be and how to make that choice.

• Image processing: 5 tools you will love
• A comparison of micro-frontend utilities
• How to choose the right content management system
• What to look out for in a good ORM
• 5 performance metrics of a good UI library

Choose to accept the fact that we are here on Medium to learn, and not to listen to rants and waste time on unhelpful rhetoric about yet another tool that fell out of your graces. Less is more: sometimes it’s better to not write than to write something that is baseless, unargumentative, underresearched, and unconstructive. Impulse writing belongs in your diary and not in public domain.