Axioms are self-evident truths. The axioms of Software Development isolate key basics underpinning successful software development. These axioms build on each other. Understanding the first one will aid your understanding of the subsequent ones. This is part of the series on the Axioms of Software Development. If you haven’t read the previous axioms - you can see them here.
It’s my aim that by helping you understand these axioms, I can help you resolve problems associated with coordinating developers, time and resources and ensuring your software project is successful.
5. Be ready to go live
In axioms 1-4, I covered principles that outline how to approach software development. Now it’s time to get dirty and start coding.
Where do you start and what gets first priority for your development hours?
I decide what gets done first by looking at it this way: In the first 2 or 3 weeks of a project, it should be possible for me to push the application live at pretty much any moment.
That’s right, after a few weeks, be in a state where you can deploy the code to the internet and let users have at it, so both you and they gain some benefit from the software you are developing.
Does that mean the system is DONE in 2-3 weeks? No. But it should have enough features to be live—not necessarily to DO anything useful—but perhaps it has something in place allowing the users of the system to sign in and play with it.
The goal is to start the process of constantly delivering a product, thus allowing the people paying the development bills to “call it” at any time and go live with what they have.
This goes right back to the first axiom - features required will always exceed available budget.
This is why you need to build critical features first.
The goal when you start any software project should be simply: “How fast can we get this thing live?” Even if it doesn’t have enough features to make it really worthwhile, you should have enough features to enable the basic use case to go live as soon as possible.
You need to achieve that as fast as you can.
Because the truth is, your budget could run out at any point, and you don’t want to be left with an application that doesn’t do anything because there are a lot of half-done features with nothing really talking to anything else. You get more benefit from focusing on one key aspect and getting it functioning than you do trying to do everything at once.
Benefits
For instance, we built a wonderful product for the State Library New South Wales. We deployed an online platform allowing crowd sourced audio transcriptions of historic audio recordings. You can see it here: amplify.gov.au. Their budget was tight. We had only a few weeks to create a transcription platform, load recordings into it and make sure users could contribute.
Four weeks to accomplish something of this magnitude is practically unheard of. But the State Library had chosen the New York Public Library’s Transcript Editor platform as the model. It was an existing open-source project we could fork on GitHub. We figured that an MVP was possible, and we threw one of our best developers at it. Four weeks later, he got the platform live.
And by ‘live’ I mean it was accessible on the internet by users. It was by no means perfect. The first release had the audio recordings practically ‘hard coded’ into the platform ‚Äî there was no ability for the library staff to add new recordings. But volunteer transcribers could contribute to the historical archives and the first few hundred transcriptions were able to be digitally corrected.
The site was live, and it was in the hands of the users. And it was LOVED! The application in its initial form won an innovation award and based on the initial success, the project gained further financial backing.
In the years since the project launched, we expanded on it and have created new features like the ability of the staff to add recordings to the library without needing a developer. It was a fundamental desired feature but was not required to launch the platform and thus was initially omitted. We have improved the look and feel of the site and the functionality for crowd sourced transcriptions.
But and it needs to be said again, without that initial release on that initial (very limited) budget, the project would never have won the innovation awards it did, nor is it likely to have been considered for further funding of features.
This is a very good example of the benefits of being ready to go live rapidly.
Summary
Being ready to go live as soon as possible forces things to get done in a more efficient manner and is a crucial axiom to successful software development.
Getting your project live and in-front of users also helps you demonstrate to your end users and stakeholders that the project is viable. It helps your project gain momentum or keep momentum and interest, so the project does in-fact get completed.
After commencing development, the speed of getting your application ready to go live is directly proportional to the success of the endeavour.
Are These Axioms Helping You?
I hope you are getting value from these axioms. Please send me through your feedback and thoughts.
