Devs are everywhere. Your life wouldn’t be what it is today without their fingerprints on a software system you take for granted. You wake up to an alarm on your phone. Dev. You find your podcast app and play the morning news while you dress. Dev. As your coffee brews, you scroll through emails on your computer. Dev. To-go cup in hand, you hop in the car and the monitor flicks on. Dev. You get to work, settle into your desk, and your podmate swivels around to say, “Did you watch Mandalorian yet on Disney+?” Dev. You get the idea.
There’s an amazing resource out there on Planio’s blog that breaks down the dev process in detail, check it out here. That said, it’s content heavy. If you’re a nondev and are never planning to be a dev, then we’ve broken it down even further for you. Here are the stages of software development:
What are we getting into?
During the prep stage, we need to ask ourselves several questions. Does it match our company's mission? Do we have resources as in the right people and tools. Does it fit in our schedule and meet the customer’s timeframe? And lastly, what's this going to cost?
The nitty gritty.
We're talking nuts and bolts like security measures, what input/output data is needed and figuring out if other tools need to be integrated. Big picture, we're defining the problem-solution and answering who's going to use it and why.
What you see is what you get.
Design & Prototyping
There's options here. Maybe, we're starting small with just wireframes. Or maybe, we're mocking up a prototype to test. Or neither, and we build out version one. Then, we're tossing it off the deep end for quick but critical feedback before going back to the drawing board with new guidance.
Do not disturb.
Noise cancelling headphones are on. Lights are dimmed. Now we code. The factory is in our laptop, and we build from sunrise to sunset everyday. This could be a short sprint or one long haul depending on the process.
The proof is in the pudding.
Feedback & Testing
There's no crying in coding. Or was that baseball? Anyway, we toss our product into the open air and see how things go. This usually is multiple cycles of in-depth testing with beta users or tracking the way customers use the software.
Hit the road.
Launch. Kick off. Get the show on the road. However you say it, deployment means one thing: send forth code into production and release the product or updates to users.
This is the song that never ends.
Maintenance & Updates
It goes on and on my friend. Routine maintenance obviously, but also product adaption As the software lifecycle continues, the process repeats itself as customers' needs scale or change entirely.
We could say, well that’s all folks, but it’s not that simple. This process isn’t exactly in that order, and when you see it in practice, everything seems strange. That’s because there are different ways of tackling the dev process, the most popular being waterfall and agile/scrum. Oh, and just remember, when you hear the dev team dropping the word sprint, it’s unrelated to running or the cell service company.
Here’s a rapid fire breakdown of a handful of methods:
One way, or another.
The two main methods tackling dev process:
Doing the dev process in order. Great for shorter projects or strict company policies/structures. Not great for flexibility, adaption or new product releases.
Agile or Scrum
Ready, set, build, release. Repeat. In sprints, build the bare minimum and launch, then take customer feedback and update continually and add features. Great for startups. Not great for strict budgets and timelines.
Meet me in the middle.
A mix between Waterfall and Agile:
Plan, build, release software with a complete feature. Then repeat the process and release the next complete feature and so on. Think incremental so each step is a full increment.
Plan, build, release “take one” with the basics or small bits of all the features. Then upgrade with “take two.” Then “take three,” etc. Think iterations so each step is reiterating the last but better.
The waterfall with checkpoints so you won’t fall all the way down. Basically, this means testing throughout the process, even before coding—which is great—but hold your breath, because this also means no early prototypes are produced.
Around and around you go, combining all of these methods to avoid risks. However, checking all the corners means more time and higher costs. Not really practical or realistic for most companies.
Is your head spiraling? Now, you’re feeling like a dev. At Ario, we’re deep in the scrum. Sprinting. And sprinting. And sprinting. Until we are out of breath, but with one fine product at the end.