Towards the end of 2019 I started developing Sigbla. And just now, around half way through 2024, I released the first beta version. It’s a Source Available type of software, different from Open Source, but still developed in the open. But it wasn’t until towards the end of 2023 I even put it up on GitHub.
In other words, a very slow process. And all just to be able to put some numbers in a table!?
This is different from my usual approach to software development, especially in a commercial setting. I’m a firm believer in reducing the feedback loop, ensuring something is made available quickly and frequently, in order to obtain observations and reactions from end users and others involved.
At its core, this approach stems from the fact that making people describe what they want, especially with regards complex systems like what software usually encompass, is difficult. It’s a lot easier to gather some initial feedback, put some software together, and then basically ask, “is this what you wanted?” That second round of feedback is usually of significantly better quality that the first round.
Who you’re asking can be internal stakeholders, but might also be the market overall, i.e., your customers and potential customers. Often you see this talked about as A/B testing as well.
For me, this is basically the essence of agile methodologies – working in ways that allow us to shorten the feedback loop, and continuously try out ideas and get feedback on them. These experiments allow us to iterate towards something with product-market fit.
But for Sigbla, I took a different approach. Partly I took that approach because I had myself to ask for feedback. I’m an example of the core user of the APIs that constitutes Sigbla – someone who wants to work with data in the form of a spreadsheet, but not with formulas in cells, but rather code interacting with cells.
But more to the point, I took this approach because I feel holistic APIs is something that needs time to mature.
Taste isn’t straight forward
I’m a fan of whisky, and whenever I have some, if I don’t know the particular brand already, it will take me some time to figure out what I like about it. Sure, I know my preferences, and can quickly determine if a particular whisky falls within what I tend to like or not. But what are the specific details I like about any one of them? That will take some time, ideally with a delay between each time I try it.
Taste takes time to develop, and I took the same approach for developing my taste for the Sigbla APIs. Do I really like one particular aspect of the API? I don’t know, I’ll need to give it some time. And through that time consuming process I’ve experimented and refactored a lot. If you were to go through the commit history, you’d be able to see these ideas develop over time.
Another consideration for doing it like this is that is reduces “the chaos.” By that I mean that we can iterate towards a large complex solution with a lot of people involved just fine, but it does add a lot of variance. It’s difficult to do both that and also have a very clearly defined holistic approach. It’s a bit of a trade-off, and APIs defined by different groups will have differences in approach. The Sigbla APIs are, what I would consider, opinionated. And they try to apply that opinion across the whole framework, with time used as the tool to allow for that.
Of course, Sigbla has been a side-project. So it’s not been like I’ve always had the time or energy to work on it every day or every week. But even if I had been able to dedicate my full attention to it, I don’t necessarily think it would be able to force that development process to be much faster. Maybe by half? I don’t know, but the point was never to rush anything out, but instead to give it time to mature.
What comes next?
I don’t want your takeaway from this to be an excuse to never develop software quickly. Most software developed is fairly short lived, something to meet a particular current commercial need. Some of it might end up sticking around for a while, but getting something out quickly is the environment most of us software developers operate in, and for those speed over a holistic approach is of the essence. But there’s a difference between that and software built to provide a language, protocol or framework.
What I’m really looking forward to next is to build on top of what I’ve built, because it now feels ready for that. I might do one or two more beta releases of Sigbla before moving it to production ready, but what comes next for it will be various utilities, additional UI components, more integration options, etc. Those are things that fit a lot nicer into a shorter development cycle, as I can now build them on top of stable foundations.
And I would love for some feedback from you now, as I let you sip the bottled API experience I’ve put together. I’d enjoy some good discussions on that if you don’t mind.