The Age of a Software Project

Does it make a difference whether your project is 2 or 3 weeks old? Probably not. Does it make a difference whether it’s 3 weeks old or 3 years? Probably very much, yes.

I was recently talking to a friend about how you work on a project must change depending on where in its lifecycle the project is.

Is it still young, unproven, doesn’t have product-market fit and is in an exploratory phase?

Or did you find your customers and you can’t keep up with the demand so that you find yourself now in a scaling phase?

Or maybe the peak has already passed and you’re now in maintenance phase?

It matters and should affect how you work.

When you’re exploring by definition you don’t know what will stick, so it’s fine to experiment, to play around. Meaning: you don’t have to follow The Best Practices all the time. Maybe you have less tests than you think one should have. Maybe one bit of the architecture is popsicle-sticks-and-ducttape. Maybe some load-bearing code has a fat TODO: we shouldn't do this above it. In this phase there are a lot of things you don’t know yet – which part of the project is important, what is truly the most load-bearing bit, what will have to change the most often, what breaks frequently – so you need to learn, as fast as possible.

Once you need to scale, you’ll learn even more: now you find out where the bottlenecks are and what will break and when. This is when you need to make the load-bearing parts actually load-bearing. This is when you wrap the things that should not ever, ever break again so thick in tests that regressions become nearly impossible. It’s time to put a proper architecture in place (or adjust whatever you had in place); an architecture that represents everything you learned about how the system is used and how it should work.

Once the party’s has found a nice groove, you’re in the maintenance phase. This is when you are able to sort your files into buckets that describe how often they change: ah, these two we haven’t had to touch in 2 years; this one and that one we have to change weekly, because we need to make slight adjustments to business logic; these files over here, we’re working on those because we realised it’s been a constant source of bugs for years.

If you don’t know where you are on the timescale you end up doing the possibly right things at the wrong time: worrying too much about performance bottlenecks when you don’t have a single user yet or hacking stuff together in a very important part of the project and breaking it for customers.

All of that is, of course, easier said than done. It’s hard. My friend and I both said that it’s the mark of very senior engineers to be able to seamlessly switch their mode of working depending on which project they’re on.

Especially in our world of programming where best practices and patterns are usually presented without context. It’s often “at company X we do Y to great success” but it would be more valuable if it was “at company X, on 4-year old, hugely successful project Z, with 60 engineers working on it, we now discovered that Y is much better than these 5 other things we tried years ago”.

(I was really impressed when listening to Kent Beck explain that at Facebook/Meta they are so aware of these lifecycles that they put different teams on projects depending on where they are in the lifecycle, which he calls the 3x curve.)