This month I want to highlight a video, Build software that lasts!, by the Changelog YouTube channel. This excellent video features Bert Hubert, an accomplished technologist. In this interview Bert shares his hard-earned wisdom on several topics, all of which resonate with me as an experienced software developer and leader (note: this interview is over an hour long, however the key points in this month’s article come from a 23 minute block starting at 20:44 – which is where the video below begins).

I only curate and share media I have personally consumed, and I can guarantee the interview is well worth the watch. Here are some of Bert’s key points:

1. Building software is fragile. With 1K+ dependencies per project, it is fragile to build even simple software. Keeping software updated is equally challenging. This development environment is not conducive to creating durable products that continue to work with minimal future investment.
   • My take: Businesses want to invest in creating software right now, but try to minimize or ignore software maintenance costs in the future. Any project that is meant to last needs ongoing maintenance, and not at the expense of other work.
2. Focus on simplicity. There is no harder job than debugging clever code from years ago. Prioritize simplicity and don’t over-design for a predicted future.
   • My take: Simplicity often takes more time to design than complex solutions. Simplicity comes from solving only the problems you have, and not trying to future-proof your tech (spoiler: your predictions will be mostly wrong).
3. Invest in growing and keeping your people. Software is difficult, however the difficulty only increases with a revolving door of employees. It is hard to compensate for knowledge walking out the door every couple years. Keeping your people engaged and growing creates an environment that enables high quality development through employee retention.
   • My take: Although the world has normalized towards two-year job changes and contractor-heavy work forces, this is causing heavy strain on software development. For the reasons stated above, creating software is known hard. Creating and maintaining software with a constantly rotating team hinders us from focusing on simplicity, and therefore contributes to the complexity.
4. You fix the pain you feel. Organizations often create barriers between software developers and software operators. Writing simple, maintainable software requires prior experience of feeling the pain when you make a mistake.
   • My take: Amazon was culturally designed for teams to feel their own pain. The often expressed as teams owning their on-call rotations (no SRE teams), however it also extended to other aspects of the culture. In that vein, at 2K I recently asked to be paged for 100% of all high severity incidents in my group. Although it will likely suck, I believe that I need to feel the pain of being paged in order to deeply understand our consistent problems, which in turn, will incentivize me to help drive solutions.
5. Avoid Version 2 syndrome. Don’t write a version 2 of your software that fixes all the problems from version 1. You will most likely miss the mark and create new software that has an equal amount of new problems, which wastes time and money. Instead, prioritize housekeeping and ruthless simplification.
   • My take: +1000. Read more on this in my September 2024 article.

“We all say we like simplicity…the only people that do this correctly are the people that feel it in their bones. That when they’re typing in something complicated, they worry already about the 3am debugging session that’s gonna ensue five years from now.”

Bonus quote: “The best way of writing simple code is having been on call.”