“Threepio! Shut down all the garbage compactors on the detention level!” Luke yelled while being smashed in the garbage compactor. So Threepio was a little untrained when it came to operating trash equipment, right? Well, he was just a protocol droid & he did eventually get the job done so Luke Skywalker could go on to save the galaxy.
Building software is a bit like building a droid, only instead of building the hard metal body it is more like training your robot in a new skill. But before you build anything you ought to have a plan.
The Software Development Life Cycle or SDLC
Long words and acronyms make things sound more complicated than they are, it means when building software: plan before acting.
What job do you need done?
There is a reason you are building in the first place. What pain do you hope your software will solve for you or others? Maybe you don’t need a protocol droid, maybe you need one of those tanky R2-D2 units. Having a clear use case will be key to your software’s success. Think of your favorite software programs: what pain do they solve for you?
Plan it
Blueprinting time – before anyone types any code you can map the entire project and process out as much as possible. How will the “front end” look (the part that your users will see) how will the “back end” look (the part that your developers will see)?
Do it
You’ve got your plan but now you need to manage it. You need to know something about managing this process, mainly: it is not like managing other things. This is a creative process, even with the nice blueprint you’ve created. Creative work is less predictable than production line work & so you will use an Agile process.
You can think of Agile as a hands-off, self-managed, let people have the space to think & be creative, method of managing. This doesn’t mean you don’t have deadlines but it does mean you shouldn’t micromanage every step of the process. Even if you are a developer yourself you just don’t know what needs to be created at the brick by brick code level. & if you think you need to micromanage this process you are either in the wrong line of business or you have the wrong people.
Agile works in sprints, often 3 week chunks of time where teams estimate what value they will produce in those 3 weeks and report out on a regular sequence before planning the next sprint.
Test it
Test your build early and often in the process. There is nothing worse than having a bounty on your head because your protocol droid failed Jabba the Hutt. Test the small parts, test the big parts, test the parts working together. You’ll be glad you did.
Deploy it
Eventually you have to set your birdie free. We’ll talk about the advanced ways that we’ll do this in the Dev Ops post, but for this context you’ve got to have a roll out plan, will you stage it, release in smaller steps, to smaller clients, go big at once? Whatever your strategy, you need to think about a worst case scenario plan – if everything hits the fan how will you pull back and reverse it?
Improve it
Finally, you are in the wild, but you are not done. Here you’ll constantly gain feedback, implement new bells and whistles & eventually the feedback will come that you many not have a viable software anymore and you’ll need to retire your build & the circle of life for your software will be complete.
Now that you’ve seen it from 10k feet, let’s get a little closer and see what the actual build looks like.
