Chris McCormick

"How long until it's done?" It's the question every software developer dreads. John Carmack famously responded with "when it's done." He knew the inherent complexity of software development. Software estimation is hard.

It's not impossible though. Carmack walked back "when it's done." Scopes are flexible. There is data. We have shipped before and inferences can be made.

Why measure?

Knowing your shipping velocity is incredibly useful. Even a ballpark figure is helpful to make better decisions, set realistic expectations for yourself and clients/bosses, prioritize projects effectively, and generally reduce the stress of the unknown.

Time is the most precious resource we have. As a solo dev and compulsive project starter I have to worry about the opportunity cost of starting a new project. I need to know what I'm on the hook for if I commit to shipping a project. As a freelancer I need to de-risk projects for my clients and myself so they run smoothly and everybody wins.

So I analyzed 36 of my shipped projects. These are my results.

How I measured

• I used git summary to analyze 36 shipped projects and track the days active and commit velocity.
• Days active means any day on which a git commit was made in a project. For me this translates roughly to one part time day of dev work (about half a day, from a previous analysis).
• Commits/Day is just total commits divided by days active.
• Weeks to Ship is days active divided by 3 (my average part-time days per week on a project).

Notes on measuring

"Shipped" means the software is online, does The One Thing it's supposed to do, and real users are using it. It doesn't mean the issue tracker is empty. I've basically ignored ongoing maintenance for the purposes of this analysis, and I excluded projects that have become long term maintenance projects.

I work on multiple projects at the same time. That's why I work 3 part time days per project on average. I know from measuring hourly invoiced client work that a day active on a project roughly translates to one part time day of work.

One big caveat to note is about LLMs. Almost all of this software was written before I adopted LLMs into my workflow. I'll say more about the impact of LLMs below.

You can certainly argue with the methodology here. Number of commits is similar to lines-of-code - it is at best only loosely correlated with productivity and software quality (and sometimes inversely correlated). It's an imperfect measure. There's a lot of uncertainty in "approximately one part time day of work". In the end the goal was not to get perfect values but rather to get ballpark figures to help me calibrate, plan, and make decisions.

Results

Note: you can find the "raw data" table below for the full dataset.

Insights

Client projects follow a pattern: While they range from 5 to 129 days, there's a concentration in the 15-56 part-time day range, or about 5-19 weeks of calendar time. So what I can tell clients is an MVP will probably take 2-4 months of calendar time from start to finish. Simple projects can occasionally be completed in under a month. More complex ones might extend beyond 4 months. I can divide client projects into smaller apps and MVPs versus longer projects requiring more maintainance and updates and use that to inform and schedule client work.

Revenue-generating projects take longer: Micro-SaaS projects in particular take an average of 76 days (about 25 weeks), which is longer than client work. More generally all revenue-generating projects took longer on average (54.4 days vs. 37.6 days for non-revenue projects). The added complexity of marketing, payments, and other business jazz, creates overhead that is easy to underestimate. It takes more effort to build things people pay for. It's also more risky than client work. Most of these projects fail to generate much revenue.

Game dev is consistent: My games take 16-28 weeks with a somewhat consistent velocity. That suggests game development is quite predictable, which makes me want to build more games. If I know what I am getting into it makes it a much less risky proposition.

Music software is worth focus: Music software is both fun to work on and reliably generates side-project income. Even small projects can generate some income. I already knew I should focus on music apps, and this analysis backs that up. I can probably build small online music apps in 20-25 days or 8 weeks each and increase side-project profitability. That said I seem to be less productive on music projects judging by low commits-per-day. I'm not sure why that is. Maybe because music apps are more technically challenging to build.

Commit velocity varies by project type: Games and client projects have the highest commits per day (5.74 and 6.01 respectively). I think that's because I'm directly accountable to somebody else with client projects. Games are just fun to work on so it's easier to put dev time into them. As noted, music software has the lowest velocity (3.77) even though I enjoy working on it.

How I ship

There are three main components to my stack that help me ship fast.

1. ClojureScript. They say programming language doesn't matter but Clojure definitely makes me faster. It's a highly expressive language, which translates into fewer lines of code per feature. Less lines of code, as well as other language features like immutability and functional code, means "faster to develop" and less time wasted on bugs. Then there's the great tooling with a strong focus on iterating during development.
2. Piku. I ship multiple apps onto a single Linux VPS with Piku. Deployment is a simple matter of "git push". This means I don't waste time configuring things, and it's far cheaper than other options for projects that don't take off (which is most of them). As an open source project it is also quite hackable if I need to do something special. [Disclaimer: I'm a sometime co-maintainer of Piku.]
3. Project management. You can watch a video I made about how I project manage myself using GitHub project kanban boards. Absolutely key is to constantly manage scope creep. I am the biggest source of scope creep and the technique to manage that is keeping two lists - one for the critical path and one for "later".

A note on LLMs

I performed this analysis before adopting LLMs into my workflow. With LLMs many development tasks are now significantly faster. I don't want to oversell this, as there are definitely many times when you go down an unproductive rabbit hole trying to coax the LLM to actually solve the problem and it becomes a net negative, but when it works it's like magic and you can shave hours of work off a task. One other negative is generated code with errors that passes testing but has hidden bugs.

Probably three things will improve to make those net negatives less likely: 1. Software developers like me will learn when and how to use LLMs and when to avoid them. 2. The tooling and prompting will improve to eliminate the failure modes. Maybe one day the LLMs will know when to say "I'm not going to be good at this task, don't waste your time". 3. Verification and testing methods will get better to help the models stay correct and recognise and fix their own errors.

So it will be interesting to re-run this analysis in a couple of years on projects where an LLM was involved and compare the results. I expect the number of days to build the same type of projects will trend lower.

These days, armed with LLM tooling, I find myself taking on small projects and bits of situated software that I previously would have been too busy for. That trend will probably continue and more custom software will get written in less time with LLMs in the loop.

On the whole, having a natural language machine intelligence at my finger tips when coding is not something I expected in a million years and is quite incredible! I'm very grateful this timeline came to pass.

Conclusion

It's useful to know approximately how long a given piece of software is going to take me to build. I feel more confident in planning now. I can roughly predict how many web apps I will have shipped by the end of the year. I can be more confident in giving client estimates. I can take on some fun projects like games and small tools knowing they aren't going to eat up all of my available dev time.

I highly recommend running the same type of analysis on your own codebases. All you need is a bit of git spelunking with git summary and then some of logging of your hours to get ballpark figures for your own productivity like days-worked-per-week and hours-per-commit.

One final thing I am incredibly grateful for is that I get to write so much software. I'm obviously addicted to it. The ratio of client work to side projects is skewed towards doing my own thing, and I know that I am very lucky to be able to choose to spend my time on what I want. It's a huge privilege.

Raw data