The Never Rewrite Podcast, Episode Thirty, Investing in Yourself Beyond Education

Isaac and Jeffrey discuss ways to improve yourself outside of traditional means like college, courses, or reading.

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

A Garbage Collector in 2 Shell Scripts

My previous post about a creating lightweight garbage collector for settings was a little obtuse.  This post is an example implementation for companies using LaunchDarkly and Gitlab.

Context, You've Got a Mess of Distributed Settings

Remember, this is a technique for getting a handle on your settings AFTER you’ve created or inherited a distributed mess.  Not making a mess in the first place is always a better idea.

This technique is to help you get started cleaning up a mess.  A mess is an ambiguous problem, it doesn’t have a central mass.  There’s no “worst” and no particularly good or bad place to start.

A Garbage Collector will help you get started by showing you the easiest things to clean up!

Step 1 - Extract Your Settings From LaunchDarkly

Create a shell script, extractSettings.sh

Calling ./extractSettings.sh <your api key> will give you a list of setting names, one per line.

These are the unique strings that you need to search for in gitlab.

Step 2 - Search Gitlab for Setting Strings

Create the second shell script, settingsToProjects.sh

Calling “./settingsToProjects.sh <your api key>” will give you a directory full of files.
Note: You need an admin level API key so that the script can see all projects.  Otherwise you might miss some references in projects you can’t see.

Each file will be “settingName.txt” and contain results like this:

“project_id”: 1
“project_id”: 15
“project_id”: 243

Find the Unused Settings

This doesn’t even need a script, run:

This will give you a list of every setting and the number of projects it is used in, sorted highest to lowest.  Anything with 0 lines is used in your codebase, 1 line means that it is referenced by one project, etc.

Take Out The Garbage

Start with the zeros.  Any file with 0 lines is either brand new, or no longer used.  That’s an easy check in LaunchDarkly.

Next, check for the single project use cases.  Some of those will be unused strings in constants files.  Clean up the constants files, and clean up the settings that fell to zero.

Because your garbage collector is tracking references, you can stop at any time.  You’ve automated the massive data gathering element, which makes cleanup cheap and manageable.

The Never Rewrite Podcast, Episode Twenty-Nine, (F*ck-Up Friday Series) The Saleswoman Who Faked Cancer

A non technical story of deception, good deeds with terrible consequences, and weak HR.

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

The Never Rewrite Podcast, Episode Twenty-Eight, Making Non-Compatible Changes During Long-Running Upgrades

Sometimes an upgrade to a new version of a framework takes weeks or even months. What do you do when you need to make changes to areas that are being affected by the upgrade?

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

The Pause

A common component of code rewrites is The Pause.  No new development, just for a few months, so that developers can replace the existing code. After the rewrite, development will be so much faster!  We will quickly come out ahead of where they would be without The Pause.  

I have seen managers, directors, and even CTOs go to stakeholders and convince them to allow a pause.  No matter what everyone agrees to, new development is rarely fully paused, the rewrite is never finished by the original date, and unforeseen events always occur.

Put aside the reality of why The Pause won’t work for a moment and examine the premise itself.  The Pause is all about getting tech what it wants on the assumption that this will make things better for everyone in the long run.  The Pause excludes all other departments.  Basically, The Pause says:

Yes, in the past, we failed to understand and anticipate changes from the rest of the business.  We made our life so difficult that we can’t keep making changes for you.  But don’t worry your pretty little head, we are so much better at understanding you now!  

We are going to go off by ourselves for a few months and create new technology that will handle and anticipate all of your future changes.  We understand you so well, and our work is so difficult to explain, that we are going to do this work without you.

The Pause is an insulting fool’s errand.  If the technology group were capable of anticipating future changes by themselves, they wouldn't need a rewrite.

Instead of asking for The Pause, try a dialog with the rest of the organization.  Bring them in instead of shutting them out.

The Never Rewrite Podcast, Episode Twenty-Seven, The Ticket Master – Computerizing India’s Railways with Aadil Farid, Part 2

Special Guest Aadil Farid joins us again to continue his discussion on the harsh realities he confronted when he led a team that computerized ticketing on India’s Railways in the 1980s.

This episode goes deep on empathy for your customers and fighting internal corruption with code. If you love stories about fighting the good fight, you'll love this epsiode!

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

The Never Rewrite Podcast, Episode Twenty-Six, The Ticket Master – Computerizing India’s Railways with Aadil Farid, Part 1

In Episode 26 of Never Rewrite, Special Guest Aadil Farid joins Isaac and I to discuss the harsh realities he confronted leading a team that computerized ticketing on India’s Railways in the 1980s.

Learn how Aadil had to get around hardware constraints, corruption, and software issues. In some ways everything was different about development 40 years ago, but in many respects things are exactly the same. Maybe not the part where a computer crash caused a riot that needed the national guard to put down.

If you want to go deep on how software can be a positive force for change, you won't want to miss this one!

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

The Never Rewrite Podcast, Episode Twenty-Five, A Rewrite Success Story with Brian Genisio from Khan Academy

In episode 25 of Never Rewrite, Isaac and I are joined by special guest, Brian Genisio, from Khan Academy. Brian walks us through their successful 3.5 year rewrite that wrapped up in early 2023.

Learn how Brian’s team was able to achieve the nearly impossible act of successfully completing a rewrite using many of the techniques we’ve talked about in the past, plus some brand new ones! If you want to learn about what it takes to do a rewrite, buckle up!

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

Rewrites are Waterfall

When you commit to rewriting existing software, you are committing to a waterfall process.

To succeed you need to move through the process one phase at a time.

First you need to determine the requirements.  All of them.  In excruciating detail.

Second, deliver the requirements and nothing else.  

Resist the urge to improve anything except code quality.  Don’t add new features.  No customer facing improvements.  

Burn down the requirements list for month after month until you finish.

Leaders who have delivered successful rewrites often describe the process as one of the greatest accomplishments in their career, but they never describe it as fun.

The Never Rewrite Podcast, Episode Twenty-Four, When AI Writes Your Documentation

AI tools can now write your incident retrospectives. Do developers lose by not formalizing their thoughts by writing?

In episode 24 of Never Rewrite, Isaac and I weigh the pros and cons of having AI write incident retrospectives and other forms of documentation.

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if your thoughts about the value of writing.

Site Footer