Good morning, and thanks for spending part of your day with Extra Points.

As a quick reminder: I will be in Las Vegas from Sunday to Wednesday for NACDA, and I’d love to talk with you if you’re around. I am actually moderating a discussion on “Preparing For The Future” (i.e revenue sharing, House, etc) on Sunday from 2:05-2:55 if you want to swing by, but I imagine I’ll have plenty of unscheduled time on Monday, as well as Tuesday morning-ish. Drop me a line if you’ll be in the neighborhood and want to say hi! My email address is Matt @ ExtraPointsMB dot com.

…

I recently finished reading Dreaming In Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software, by Scott Rosenberg. I wasn’t expecting a book that delves into the history of a computer program that I had never even heard of to resonate with me so much, but once I got going, I really couldn’t put it down.

Dreaming In Code follows the development process of Chandler, what was supposed to be an open source calendar and personal information management tool. On paper, the project appeared to have everything it could need to be successful. Mitch Kapor, the leader of the project, created one of the most successful software applications ever (Lotus 1-2-3), and the programming team included folks who wrote parts of the early Mac operating system or invented the web browser “cookie.” The project was well funded, the team highly talented, and a customer need clearly established.

But the project languished in development hell for years. The project scope expanded and contracted. Designs were created only to be tossed out once coding began. Core features were tossed aside as the team missed deadline after deadline to actually ship something, anything, resembling a useful information management tool.

In the end, the Chandler project ended years behind schedule and finally fizzled out in 2009, a footnote in the history of open source software development.

Rosenberg’s book doesn’t argue that the ambitious office software project died due to incompetent management, or a bad product idea, or insufficient technical prowess…but rather, more because of failures in the software design process itself.

Creating a software program isn’t like building a bridge or a desk or a lego castle. There usually isn’t an exact blueprint to follow, the component parts don’t always neatly fit together, and often, what you think you’re actually building changes over the course of the project. Programming languages have come a long way, even since the late 2000s when this book was written, but they still struggle to account for the subtleties of human language. Miscommunications happen between designer, user, programmer and machine, and those create problems.

Problems that can’t always easily be solved by simply throwing more people or money at the issue.

Reading this book, as well as my own experiences developing Athletic Director Simulator 4000, legitimately changed how I thought about the software development process…for college sports video games, silly educational games about athletics administration…or hell, anything that touches this industry, from advanced stats tracking portals to compliance software solutions.

Let’s take the video game for a second.

This interview between Robby Kalland of Uproxx and EA Sports College Football 25 Principal Game Designer Ben Haumiller, gets to part of the problem in developing anything that serves the college sports industry. The industry keeps changing so dang fast. Here’s Haumiller talking about the challenge in depicting how NIL works in the game’s Dynasty mode, where the player manages a coaching staff and roster:

It’s true, while NIL is a pretty big component of the Road To Glory game mode, where the user simulates the career of a specific college football player, it isn’t a significant part of the recruiting process in dynasty. Players won’t be asked to manage an NIL collective payroll, won’t get into bidding wars with recruits, won’t see their roster picked apart by larger programs who are actively poaching, etc.

It isn’t because the PS5 lacks the processing horsepower to compute that many variables. On the contrary, games have been able to do a decent job simulating contract negotiations and roster management since the MS-DOS era.

But think of all the massive changes in the NIL Industrial Complex since 2021. The scope of the project would have changed at least six different times if one was trying to be as accurate and realistic as possible. Changing a core system that many times is a great plan to end up with a smoldering pile of wreckage where your code should be.

I know enough about the video game’s development to know that NIL wasn’t the only real life system the team sought to emulate that kept changing before the developers could finish modeling it. I’m aware of changes that had to be made to player transfer logic, future TV schedules, the College Football Playoff Selection Criteria, and much, much more.

It’s not uncommon for software companies to spend a great deal of time trying to create (or modify) tools that make it easier to support big changes later on. When we sat down to redo ADS4000, one of the most difficult (and expensive) things we did was figure out a way to store all the game’s questions, probabilities and key variables in a database that could be easily edited outside the game’s code. It took weeks of work, but once finished, it means we can add new questions (or tweak the balance of existing questions) in under 30 minutes.

For the college football game, for example, I know a lot of technical energy went into developing tools to allow EA to render and edit football stadiums much faster than they could before, thanks to machine learning, better photo capture tools, and more. The good news is with those tools, it could potentially be much easier to add another 50 stadiums to a future release. The bad news is building those tools could take millions of dollars and months of time.

From talking to folks who were actually involved in making the dang game, I’m not surprised it took three years, or that features the team might have been confident could be included back in 2022 didn’t end up making the final cut this time. It isn’t that the developers are bad or lazy, or that corporate leadership is corrupt or incompetent. It’s just that the systems they’re trying to model keep changing, predicting software development costs (and cycles) is often a shot in the dark, and keeping large teams of developers on the same page is a struggle for even the best software companies.

I’m not surprised when I hear of schools that end up paying more than they thought they would for software tools, or that startups that try to make them often need to raise more cash, or completely reinvent themselves, or miss deadlines. On Time, On Budget and Without A Gazillion Bugs is a standard that teams struggle across multiple industries.

At any rate, my heart goes out to anybody who toils in the digital mines, building the blood and guts that make up video games, data management tools, or anything else that is meant to either serve or depict an industry that can’t make up its mind about what it wants. It’s hard enough to build a project when you know and understand the exact specifications. But when those specs keep changing? It can be like trying to take a dinner request from a six-year old.

I struggle to do that in English. I can’t imagine how you’d do it in C++.

Anyway, here’s what else we wrote this week:

I can afford to do things like go to Las Vegas for a few days to interview industry leaders, or hire new writers and other staffers, or file thousands of FOIAs, thanks to the support of our ad partners, and from subscribers like you. A paid subscription to Extra Points is just eight bucks a month, and gives you access to everything we write AND to ADS4000. I’ll even give you a copy of my book for free. That’s a good deal, IMO.

Thanks for reading. I’ll see you in Vegas! I’ll be the guy nursing an energy drink, wandering around, completely not knowing how to play any of the card games.