The longer I’ve worked in developer – and the more developers with whom I’ve interacted – the more I recognize that we all share a single trait:
We want to get our project right the first time.
Of course, this looks different depending on the type of project, but the point remains: We want to make sure that we nail not only the larger details, but the smaller details correct for the first release.
- Have we detailed all the features?
- Have we tested across every single device?
- Did we select the right font size?
- Should this feature automatically work, or should it have an element exposed to control it?
- …and so on
And even though this is true, I think that deep down we know it’s not really possible to achieve.
In fact, I’ve talked numerous times about what I call a strong 1.0 which is essentially the idea that you focus very hard on an MVP – trim the features, nail down the specifics for the first release, and then iterate.
And when it comes to that compulsive need that we – as developers (and probably designers, as well) – have, this can go along way in helping to make a better product.
Software is Malleable
Arguably, the post most important thing to remember when we’re working on software is this: It’s software.
By its very nature, it’s malleable – it can be changed over time – and that’s a good thing. Above everything else, this is what should ease any type of anxiety or fears that we won’t “get it right” the first time for our first release.
Besides, we probably won’t.
At any rate, there are a number of benefits that come with taking advantage of acknowledging that we’re building software – that is, that we’re working on something that’s really easy to change (as opposed to hardware, clearly – and that can benefit us and our projects in the long term.
1. It Results in a Roadmap
If, out of the gate, you have a laundry list of features for your application and you try to cram them all into the first version, what does that leave you for future iterations?
Initially, it leaves you with a high potential for bug fixes.
But aside from that, it also results in you having a roadmap for future versions. This means that if something didn’t make 1.0, then you’ve given your product a lifetime – and that’s awesome.
Aside from the anticipated bug fixes, you’ll also be able to give customers or users new features to look forward to with each release, rather than having everything already packed in for them.
2. Less Prone To Bugs
This particular point is a little bit off key – it’s not so much that having a smaller set of features in 1.0 means that you’re less prone to bugs, it’s just that the potential for things to go wrong is a lower because there are less moving parts of the application.
Face it: Everything is going to have bugs – it’s just a matter of how many.
If we can control the level of potential a project has for bugs, then why wouldn’t we? The more moving parts to an application there are, the more potential for a variety of bugs to work there way into the code.
Having a smaller set of features means that you have a smaller set into which bugs can work themselves, which will intern allow you to create a more robust product.
3. Focused Feedback
Finally, aside from having a roadmap for your project, and aside from being “less prone to bugs” – at least to a degree – you’re generating focused feedback because there is less material for your users to, ahem, use.
Since you’ve only implemented Feature X and Feature Y, that’s all they can report on, which is good because it helps you to collect information, data, and manage how people are experiencing your product.
If, on the other hand, you integrate Features A – G, then you’ve got an entirely different set of things that your users can interact with and to which they can respond generating much more work for yourself.
Solve The Problem (And Do So Elegantly)
Ultimately, I think that creating software is about making sure that each release is stronger than the last, and, if it does more than introduce bug fixes, it’s about creating a robust set of features that continue to help solve a person’s problem given the problem domain.
It’s not about giving them the kitchen sink, it’s not about throwing them every option imaginable either.
It’s about elegantly solving their solution, doing so over the course of a period of time, and doing so in a way that’s manageable for you over the product’s lifetime.
Leave a Reply
You must be logged in to post a comment.