New features aren’t coming as thick and fast as they used to, and all the development team’s time seems to be spent on obscure bug fixes.
We’ve all been in this situation, and then you hear the dreaded words, technical debt. We’ve all been there. And then you have the following questions of like, well, did someone do something wrong? Like, how much technical debt do we need to pay down?
We came across this recently with our apps. We realized that we built up technical debt and we needed to pause, take stock, refactor so that we can move forward again. But as I was doing this, I read a blog post by Nima Badizadegan on abstraction. And then there’s lots of really good points in it, but one kind of that really got me thinking was about how each project, each, you know, software project we have, each website that we build is made up of requirements, values, and assumptions. Where values are kind of like your, your non-functional requirements. And we don’t really talk about those very much.
Like in a discovery process, you’ll, you know, maybe spend, spend, like, you know, the last part of it, just token discussion about performance and security. But they’re not really conscious parts of our project. Both, you know, during the project itself or then afterwards. And what Nemo was talking about in this blog post is that your values change and your software is a culmination of your values.
And so in our example, technical debt was actually just our values changing. At the beginning of our projects and our apps, you know, we just were trying to get one to market. So time to market was our value. We wanted to validate like that. We could build a SaaS app on BigCommerce. We wanted to validate our idea.
So getting it out there was the important part. But now we’re eight apps on and we’ve got, you know, lots of production stores using our apps. Our values are naturally completely different. New features, new apps are still important, so we have that value. It’s still there, but it’s just diluted by other values that we have.
We now have values around maintainability. We want a consistent experience across all of our apps, and so we want to be able to update each one quickly, keep it up to date. So, but also enable us to spend that time that, you know, we could have spent just manually making our codes to each of our eight apps, which is what we were doing for a while.
We don’t do that anymore, so we don’t, we don’t waste half a day to a day just doing those one line changes. Now we can move more quickly, still focus on our new features and new apps. So I thought it was really helpful or I found it helpful to think about the values that we have. So when , the next time a development team comes up and says, you know, you’ve got technical debt, to be thinking about the, the values that perhaps the first version of that feature or that software that you were using had, and therefore what you have now, how has it changed and how we might, what is appropriate in terms of the changes you might make? I think, you know, just the one last point to call out is the technology that you choose has its own set of values baked in, you know, every project, so, you know, all the way down.
So for us, for Laravel it has its own values that it abides by. And for us, many of those align with the time to market. Convention over configuration is a software paradigm that lends itself towards if you can do things in the Laravel way, you’ll be able to move quickly. If you want to take control of everything and customize everything, then you’re gonna have a bad time.
So, yeah, I hope that’s helpful. Thinking about values, thinking about the importance of these non-functional requirements, they’re not just the things you tack on at the end to kind of round off a requirements document. It can be useful to think how these mature as not only your business changes, but also each individual feature.
I don’t think it’s uncommon for new features to prioritize time to market and then needing a bedding in period if we don’t want to throw them away when we want to keep them, it’s probably time to take another look at them to kind of finish them off as it were.
So, that’s all for me for today.
I hope that was helpful.
