1. If someone asks when something will be done, they are asking for the date when they can use it.
   
2. Every day, ask yourself what could happen to make it so the software won’t be ready to use by that date and do something about that.

The result of project management is that the software is ready to be used on the publicized date.

The details about how to figure out the date should be, what it will be, negotiating that difference, how to communicate it, how to change it, who “they” are, what “they can use it” means, changing that definition, what kinds of problems could happen, what to do about a problem, how to track all of this, etc is what project management work is, but in the end it just boils down to those two things.

I wrote Unit Testing Old Code in January 2004, and I stand behind the recommendations. In short, use unit tests to accomplish what you are trying to do right now. Tests will help you refactor and optimize without breaking something, they will help you represent new learnings as you read code, and they are a good thing to write to reproduce a bug before you fix it. In all three cases, it’s a means to an end.

Later that year, Working Effectively with Legacy Code [affiliate link] came out with the definitive advice on how to add tests to a codebase without them—introducing the concept of seams. Generally, seams are a way to change what code does with external control. It might not be the way you’d design it from the start, but it’s a good way to migrate untestable code to being testable. I reread it recently and the techniques are still useful and easy to adapt to modern languages.

If I were to update my advice from 2004, I’d say to adopt diff-cover. It’s a script that filters down your code coverage reports to show the test coverage of the changes in your branch. This lets you try to hit high coverage numbers on each PR without necessarily having high coverage overall.

Other than that, if you have an untested codebase, I’d still say not to make it a project to add tests widely. It’s something I do it in my codebase even though its coverage is high. I want to keep it that way.

If you don’t have any tests, I’d get the infrastructure into place to run tests locally and in CI and a few to get a few tests going. Then, use tests to get your work done faster. I cover this in my book, Swimming in Tech Debt, which isn’t coming out until March, but I have a story of how I did this at Trello that was published in The Pragmatic Engineer.

Right after I read eXtreme Programming: Explained [affiliate link], we built a CI system at Droplets (where I worked). CruiseControl didn’t exist yet, so anyone trying to do this just figured it out for themselves. Our system was based on a physical build token.

All of our desktop machines were named after movies—the CI Build Machine was named Goodfellas. I printed out an 5×7 poster of the movie and put the manual instructions for doing CI on the back. Then, I laminated it. You needed to have this card on your desk if you wanted to commit code.

Here is what it said on the back of the card:

1. You must have this card on your desk to proceed
2. Commit your code
3. Go over to Goodfellas (don’t take the card)
4. Get your changes
5. Run the build and test scripts
6. If it’s broken, fix it
7. If you know someone was waiting for this card, give it to them
8. Otherwise, put the card back where you found it

The build and test were automated, but you did need to manually grab the card.

Doing this solved our problem of broken builds caused by “it worked on my machine” problems. Seems antiquated now, but before easy branching and merging, this one-at-a-time verification caught a lot of problems early.

Three years ago, I identified five pieces of software that I thought were “great works” that were written by one or a very few number of people. In rough chronological order, they are C/Unix, The ARM instruction set, TeX, VisiCalc, and the Web Browser/Server. I didn’t pick them based on what the software did, but they are all basically programming languages. They also are somewhat old (> 30 years), yet still exist or have a lineage of derivative projects (i.e. they were not lost).

Since then, I thought of two others. They are also programming languages of a sort and both are enabled by the existence of the web. Both are in heavy use, albeit mostly through derivatives. They are also both relatively tiny programs—more like poetry than prose.

The first is Markdown by John Gruber—you can download the original Perl at that link. Markdown is ubiquitous and finished, in the sense that it hasn’t been updated, and it doesn’t need updates.

Even the derivatives don’t need updates. In 2016 I wrote the Swift implementation of Trello Flavored Markdown by porting our web client’s JavaScript version (so it would match exactly). It was a little longer than Gruber’s original, but not by much. Once it was done, it only had one update that I know of.

The second software poem is the original Wiki software by Ward Cunningham. I don’t know if the original source is available, but I used this Perl implementation he published when I wanted a locally hosted version—it was my original second brain. I use Obsidian for this now, which (of course) is based on Markdown.

It’s funny that both Gruber and Cunningham chose Perl to write their poems. Perl syntax lends itself to writing actual poems—I have a vague memory of seeing some in Larry Wall’s Perl book. I would also note that both poems have minimal dependencies. I don’t think Markdown uses anything that isn’t in Perl. WikiWikiWeb uses Berkeley DB by default, but I trivially replaced that with simple files in my version (which I can’t find, but I do have the files, and they are just text).

They were also built in a time when it was common to build web server software in Perl (Markdown is 2004, WikiWikiWeb is 1995). I learned Perl in 1993 at my first job, which we used to replace all of our shell and awk scripts. I built production websites with Perl until 1999, but Perl was still my go-to language for scripting until 2013 when I switched to Python for web backends, scripting, and anything where Pandas would help. I’m sure Perl has equivalents for everything I do, but I never learned modern Perl.

My attempt at a poem of this nature is Page-o-Mat, a YAML-based language for making journals. It’s small, but I need YAML and PDF dependencies to make that happen. That fact about modern programming makes me think we won’t see another great software poem again.