Never Rewrite: Software Engineering & AI Coding

Isaac and Jeffrey discuss the myth of the Boy Scout rule, which is the idea of leaving code better than you found it. Isaac shares his experience of encountering problems when trying to follow this rule in a codebase with no test coverage. He explains how fixing one issue led to unintended consequences and a cascade of errors. They emphasize the importance of being cautious when making changes in old and tightly coupled code and the need for thorough testing. They conclude that while refactoring is important, it should be done intentionally and not mixed with other changes.

Isaac and Jeffrey discuss situations where software development teams are pushed to have fewer, larger releases. They highlight the challenges of big release-driven development and the need for careful planning and more QA before each release. They also explore strategies to make the problem less severe, such as minimizing the final push, using an API-first strategy, and feature flagging.

We check in with Dustin Rea, head of Red Hook Agency, to discuss where White Label CRM is with their 'turnaround story' - how they're handling 'bug hell', scaling issues, and what their trajectory is now.

Isaac and Jeffrey discuss the potential of AI-driven testing and code generation. They reference an article by Codium AI, which explores the use of AI to generate tests and increase code coverage. While the generated tests may not be perfect, they can serve as scaffolding for legacy code and help identify areas for improvement. The conversation also touches on the idea of using AI to provide business context and legal compliance guidance during code refactoring. Overall, the discussion highlights the potential benefits of AI in improving code quality and reducing risk.

Isaac and Jeffrey discuss the mindset of writing your job out of existence. They explore the idea that being irreplaceable can be a trap and that making your current role disappear in a positive way is the key to career growth. They share examples of individuals who get stuck in repetitive tasks and fail to see the opportunity to transform their work. The conversation highlights the importance of reframing problems as opportunities for improvement and the need to overcome the fear of change. They also touch on the issue of intentionally not fixing problems to protect one's job.

Jeffrey and Isaac discuss how to get started with shadowing people and solving their problems. They share their experiences and strategies for shadowing, including reaching out to the people you want to shadow, observing their tasks, and identifying areas for improvement. They emphasize the importance of shadowing during the onboarding process and the value of asking questions and challenging existing processes. They also highlight the benefits of building relationships and earning credibility by solving problems for others.

Isaac and Jeffrey discuss the topic of doing full rewrites when it comes to architecture. They explore a case where a client needed to move from a single EC2 instance to a more stable system with load-balanced instances. They discuss the parallels between rewriting code and rewriting architecture, and the challenges and risks involved.

Isaac and Jeffrey discuss the 'two clock problem' as a metaphor for software rewrites. They explain that adding a new system doesn't improve understanding if you don't know how the current system is wrong. They also emphasize that rewriting a system without understanding the current system is costly and may not be worth it. Instead, they suggest spending more time understanding and documenting the current system to mitigate the need for a rewrite.

Company culture can have a significant impact on the style of code delivery. A rigid and bottlenecked code review process can slow down code delivery and create frustration. On the other hand, a collaborative and open culture can lead to faster and more efficient code delivery. It is important to strike a balance between code quality and speed of delivery. Perfect code that doesn't solve the problem is not useful, while imperfect code that is easy to change and improve can be valuable. When considering a job, it is important to ask about the company's code delivery style and whether there is a culture of collaboration and openness.

In our new series 'fulfilling Fridays', Jeffrey shares a fulfilling software project he worked on at Guaranteed Rate, a mortgage broker company.