609: The best, worst codebase · interviews

Jimmy Miller talks to us about his experience with a legacy codebase at his first job as a programmer. The codebase was massive, with hundreds of thousands of lines of C# and Visual Basic, and a database with over 1,000 columns. Let's just say Jimmy got into some stuff. There's even a Gilfoyle involved. This episode is...

Andrew O'Brien (Sep 19 2024 at 15:13):

The thousand-column table is reminding me of the worst thing I came up with as a newbie engineer 20 years ago: The Perl script I built to make a pivot table in MySQL 3. There were about 20-30 data fields and some forum post I read said if I didn't want to buy some MS product that did multi-dimensional expressions (we didn't), just generate a massive CREATE TABLE ... SELECT with columns like SUM(IF(year=2004, stat, 0) AS stat_2004).

I had a DB table with a bunch of fields that controlled how the stat fields were combined which you had to manage through phpmyadmin and RTFSC to understand.

The webpage to actually query the thing was a PHP 4 monstrosity. I tried using OOP but it was slow and I had no idea how to profile it so I threw it out and rewrote it in a horrible imperative style. 4 years later when I left I felt guilty that it was the only thing I'd never returned to improve, but they were like "no, it works... we'll just never touch it". But they weren't counting on the fact that they had asked me to do quarterly as well as annual rollups, so they hit that limit way sooner than expected.

Lars Ellingsen (Sep 19 2024 at 15:41):

Awesome episode. This and the original blog post reminded me so much of my first job, which was also building internal software. Some random memories:

Circular reference in a giant web service project that was known - "just unload a DLL, build, see it fail, switch which one is loaded, build again, fail, then load them all and you're good!"
Dozens of schemas in an enormous Oracle database, where we used stored procedures to act as a service layer essentially (and a ton of business logic in PLSQL)
Writing our own C# micro-ORM to make working with the stored procs easier, but still keep the DBAs happy
Custom ERP system written in COBOL but where more recent logic was in PLSQL
Emailing database code updates to DBAs to be run
Data center in the basement of the building that we ran
Deploying ASP.NET sites to a file share which would update production
Refused to use the cloud even later on, when it made a lot of sense

But some things we did well:

Talked to users, all the time
Empowered developers to make users happy
The dev team got along very well and communicated a lot with each other
Produced a ton of software for the size of the team
Positively impacted user productivity (when possible... sometimes we had requirements that prevented this :joy: )
Code was actually quite reliable
Over time, set up our own weird conventions, but everyone actually followed them (so it was easy to tell what was happening in new projects)

Andrew O'Brien (Sep 19 2024 at 21:59):

I think Adam said “it sounds like a game”. Can we get an open world game where the world is a medium size moderately technical business set in the ‘00s where you have a bad, but functional codebase and can improve it in ways that actually affect the company’s performance? (That last part might be the escapism that draws people in.)

The hardest part would probably be writing a codebase that looked like it grew organically over time at the hands of a bunch of different people with varying tastes and expertise.

Daniel Buckmaster (Sep 19 2024 at 23:17):

I said this in Slack and I'll cross-post it here. Munch reminded me of Brent from The Phoenix Project, for those who have read it. The well-meaning constraint on the system through which all value flows!

Andrew O'Brien (Sep 20 2024 at 14:52):

I'm checking Jimmy's podcast "Future of Coding". Looks like they've talked about a lot of classic papers in software engineering. I'm in the middle of their episode about the Programming as Theory paper by Peter Naur that he mentioned in this interview and loving the discussion.

61 • Programming as Theory Building by Peter Naur

Are you looking for the real computer revolution? Join the club! Future of Coding is a podcast and community of toolmakers, researchers, and creators working together to reimagine computing.

Daniel Buckmaster (Sep 20 2024 at 20:45):

The podcast is really good and I personally think the Naur episode is the absolute best. Though that may be because I like that paper the most.

Andrew O'Brien (Sep 21 2024 at 13:48):

Right before I started listening to it, my boss asked me to take over a PoC from another team and turn it into something productionizable. The idea of resurrecting “dead” code has been haunting me ever since hearing them talk about it.

Fortunately they all still work for the company so they’ll be available and I will get at least one of the engineers from the original team.

René (Sep 24 2024 at 07:19):

This was exactly the interview I needed. I often fight with the frustration that the codebase I am maintaining is tedious, but this was a great reminder that the grass is not greener elsewhere, in some cases maybe.

Ian Lessing (Sep 26 2024 at 17:47):

This was an awesome episode! :star: :star: Jimmy is a great story teller and I was shouting with laughter when he told the story of the law enforcement over reaction to his bug bounty payment request.

Tillman Jex (Oct 07 2024 at 19:21):

Agreed, love story tellers! The episodes with Steve Yegge are like this too.

Last updated: Dec 12 2024 at 16:20 UTC

Stream: interviews

Topic: 609: The best, worst codebase

Jerod Santo (Sep 19 2024 at 14:54):