Six years ago Waldo Jaquith, Robin Carnahan, and Randy Hart released “De-risking Custom Technology Projects: A handbook for state grantee budgeting and oversight”. This tome was written for state legislators and agency heads that were looking to fund and conduct oversight on new custom software. Besides recording the current state of the art, the team at 18F wrote a guide to technical project management for non-technologists. On the other end of the spectrum Software Carpentry focuses on teaching academics or others new to writing software how to do so. There is still a need for a guide to commissioning (or not) custom software projects for smaller organizations and middle managers that are lucky enough to receive grants to do so. They’re not trying to compete with Google, they just need to make some pretty good software.¹

What is Pretty Good Software?

Pretty good software is practical. It is not built by wizards or ninjas, but craftsmen. It can be transformational but is typically tactical. It fits in the time and budget you have, not what you wish you had. It warns you about the different ways you can shoot yourself in the foot, but also lets you know how to bandage it up if someone else pulls the trigger.

Why not no-code, spreadsheets, macros, or AI?

Pretty good software is often birthed out of hitting the limits of no-code, spreadsheet, or other tools. It might integrate with or be prototyped with them. These interesting and useful approaches often take ease of use and UX to the extreme by leaving behind the important advancements that the field of software engineering has developed. If you’re thinking about building some pretty good software you might need to explain why. This book will review the fundamental differences and trade offs between these approaches.

Hiring Your First Software Engneer

The most daunting part of getting a pretty good software project off the ground is hiring the right people. This guide will help you understand who to look for, where to look for them, and the questions you should ask to figure out whether they will be a good fit for your pretty good software project. It will include actual questions to ask in interviews with your first software engineer. It will also provide red flags and warn you whom to avoid hiring, even if it feels like your only option.

Good v. Not Good Code

Sometimes pretty good software is built from the foundation or rubble of pretty bad software. Maybe you’re taking over for someone else who has been trying to build some pretty good software and failing. This book will provide an assessment framework to help you figure out how bad or not bad an existing project is.

How to Derail Pretty Good Software Projects

The manager of a pretty good software project has to balance a variety of interests and stakeholders. These stakeholders can show up with important sounding things to look at: security, privacy, accessibility. The manager of a pretty good software project needs to speak to all these things without having them ruin a project budget or timeline. This section will explore compliance requirements and practical trade offs when looking at a variety of issues that can derail your pretty good software project.

What Else?

Send me an email or message on Mastodon if you have ideas for what should be part of a Pretty Good Software guide. I am still in the brainstorming phase of what this should be.