Recently I was reading an article from Daniel Stenberg our own cURL benevolent dictator for life, as he defines itself here and there.

The article I am referring to is “MORE CURL HELP” and it is not the first one he writes about how the cURL team keeps track of their CLI options. I perfectly understand why. First they want cURL to be easy to use but also 265 separate command line options hide a lot of flexibility, complexity and they can confuse their user base.

I am not here to discuss the solution they adopted, I think it is simple, on point, but I want to highlight how important is to iterate over what you matter and how complicated it is.

We tend to avoid touching what works, often refactoring does not found a fit in roadmap but in reality if we do not build a process that makes us comfortable to experiment and iterate over those kinds of problems at some point they will kick back, and it won’t be a good time.

I am working at an early stage startup, and we move fast because we are validating market fit, and it requires to continuously build new features so we can measure if customers or potential customers see them as usual as we think they are.

The cost our codebase pays for such flexibility is mainly related to adopted solutions that we do not like anymore. Or that are not enough. Development ergonomics is important because it builds confidence, you feel like you own the best your codebase is turning into, and you feel great updating it.

For example, we adopted server side openapi spec and we are generating server code. I thought it was a smart move, but I am not convinced about that anymore. Recently I decided to create a fallback mechanism that gives us the ability to develop new HTTP handlers or to port old one without being locked into let’s call v0. It sounds like a little thing, but it enables experimentation at low risk.

We did the same with the code we wrote around our metadata store that relays on Redis. Moving to a “proper database” is a topic that time to time comes back. We didn’t figure out if we want to move or not but what we know is that the code that we wrote to interact with Redis is not enough anymore. Writing code patterns emerged, and now we need a way to retrofit them in. I didn’t find my way to v1 around this but I think it will look like a data migration framework to move resources we want to experiment with plus some new structure around building indexes and traversing them.