The software development cycle is a pattern of inception and growth, growth and maturation, stagnation and decay, and then the cycle repeats… usually. Like most things, this is the ideal, but not necessarily a guarantee. Real life tends to love to distance from the ideal, so what really happens with this cycle?
The cycle may repeat, but you may not be on the next turn, you might get stuck in the maintenance cycle (which feels like it never ends). The wheel has spun, but you’ve been left behind. You fell off and now you’re stuck in a ditch maintaining something you want to be done with. You may get lucky and climb out and on to the next project, but you have to start the rush and fall all over again if you do. If you spend too long doing maintenance, you may be out of shape when you get your turn.
Each aspect has its own appeal, but the situations can get messy too. The process may be romantic on paper, but it’s often frantic in practice. The ups take you up, but the downs slam you down hard. The first time you run through this process, you think to yourself “it’s just this once,” but it keeps coming and coming. Let’s see what makes this cycle tick and what can make it toxic.
Inception and Growth
You have to know what the purpose is for a program to write it right, but that doesn’t stop a lot of developers and projects from proceeding otherwise. The inception is the seed you plant and the first growth is what sets the stage for your program. You can shape things as they go, but your first growth can set the strongest pattern for the cycle. If you use the wrong assumption for workflow, how do you rectify it?
The inception has to include questions about how to potentially monetize it, how to host it, how will people use it, etc. You also have to answer how to analyze metrics for success or you risk going in the wrong direction.
This is the stage where you decide technology. Do you use JSON or XML for configurations? Is there a platform which can make or break the project? It’s also the stage you decide what teams might look like. You need the hard skills to make technical decisions, but you also need to see who can work together.
Where This Breaks Down
This is the step which can make or break the project, but it’s also the step which can be pivoted from and adjusted the most. The choice between microservices, serverless architecture, and more traditional offerings can make or break profitability and/or scalability. What do you trade and what do you get? This is also the phase where a mistake can probably get a do-over without absolutely wrecking the budget, but a missed mistake can destroy any hope of success.
If you’re a developer and you can’t make any technical decisions, this can make the entirety of the project go from exciting to mind-numbing. You might get stuck doing something in a way which makes absolutely no sense or using a language or framework that makes no sense. The timelines may not reflect reality.
This isn’t just planning, this is setting a stage for the play that is the story of development. Sometimes you draw the short straw on who (or what role) you play. If you thought you were the lead but now you’re the grip, you might be a little less than pleased to keep going. Setting the stage wrong means everyone needs to relearn their part (or quits from frustration). Anyone will get tired of feeling like the Kojima credits meme (but without the credit) on all the boring parts.
Growth and Maturation
The first phase of growth gets you out of the dirt, the second stage gets you growing towards your potential. Should you reinvent the wheel or use a library? How do you break down or otherwise use a special format? While these decisions can easily be pruned or nurtured, the wrong pruning means pain, and the wrong nurture means sapping the campaign.
This is also the phase where you want to aim for the Pareto principle to get the most out of the least (80% of the results come from 20% of the causes). How do you shape metrics to know what is worth targeting and what isn’t? You need to have a good plan and grow it to maturity. The earlier in the phase you are, the less this matters, but decisions need to be made before the growth matures or you end up with sprawl.
When do you, or do you even, bother automating a task? Will it provide results and will it be worthwhile through the development cycle? What can get you to the finish line the fastest without costing too much time in the maintenance cycle? If you can’t answer this clearly, you’re probably growing towards chaos.
The maturation process is where your growth begins to slow down and grow in a given direction. We can’t make our rodeo decisions here, everything needs to be following a plan. This stage isn’t just growth then maturation, it’s growth, and a gradual shaping into maturation. Done right, this means that the product quickly hits a minimum of functioning then begins to go through a refinement towards beta.
Where This Breaks Down
Bad decisions in the last step can rear their heads here. Someone didn’t think through the implications of a specific design decision leading to a huge amount of extra work. You have some piece which should be trivial but the language you’re using makes it a nightmare to implement and maintain. Basically, something either wasn’t thought out in enough detail, or else wasn’t properly considered.
I know I’ve spent weeks working around the wrong language for the design being implemented more than once. It gets so much more frustrating when you had no say in the beginning. It’s hard to care about a project or a language when you spend half of your time writing things you shouldn’t need with a more applicable language or design paradigm.
Rapid growth can be great, but when things get rushed, mistakes happen. The wrong prioritization or lack of scope can lead to feature creep. It’s easy to procrastinate and justify redoing something because it’s not 100%, but it throws a wrench in the gears. Anyone waiting on you for a piece is going to be frustrated and stressed out.
Feature requests can keep popping in from “above” all throughout the development cycle without any concern for whether they should be added or not. A week before the closed beta and you need to redo the whole workflow because it turns out they had more success selling it differently. As the maturation phase and similar hits, you don’t want to be adding or changing workflows, you want to be finalizing their implementations and putting everything together.
Stagnation and Decay
This is the doldrums for the average developer. This is where you have to go tie up all the loose ends and deal with all the minor bugs QA finds, each little thing which was skipped to solidify another part of the process, etc. Here’s where you hit a bunch of the 80% of the work that makes up 20% of the functionality for your program. It’s scattered in the other steps, but this whole phase is basically a lot of work for very little relative gain (though it’s essential).
Depending on the shop, developers may start being removed from the process depending on the release and the workflow. I’ve dealt with the fallout when a shop pulls their developers out too early, and it is complete chaos. Fewer people get stuck doing more unfulfilling work. Morale dips.
This phase is where the project is basically done, but needs to be cleaned up, polished, and have all the checkboxes hit. This phase is boring, but unfortunately important.
Where This Breaks Down
If you have drawn the short straw throughout the project and you draw the short straw here too, you’re going to get burned out. This phase is mindnumbing, and it also involves cleaning up and putting together everything else. If people get pulled from the project, it gets that much more frustrating. What if the previous developer didn’t document a specific bug or workflow issue and you never encounter it? This can affect your processes and be overall infuriating.
This phase is often rushed which means people are working under the gun and less efficiently. You have to have a focus, and if you don’t know if you’ll be stuck on maintenance or not, it can lead to a Groundhog’s Day level of senioritis. The days blur together as you become a widget adjuster for the project.
If there’s a clear goal and a point you get to cut ties, it doesn’t feel as bad. Unfortunately, most projects don’t tell you where you’re going to be stuck so it’s always a guess. I’ve been stuck on the maintenance team after drawing too many short straws in a row and it didn’t take a month for me to quit. It’s easy for a manager to try and overleverage their best employees, but there comes a point they just leave without something to keep motivating them. Money is good, but not living in a hellish deju vu is better.
Surviving the Development Cycle
If you look for these cues in a new project, it can be easy to tell if you should jump ship or not. Is the project proceeding in a way that makes sense or is the team chaos? Are your contributions to implementation considered or not? While, the beginning can set the stage, a lot of it can be salvaged with the right adjustments (though it’s still stressful).
Once you make it past the very beginning, how do the team leaders and management adapt to issues? Is there anxiety and dread, or just minor changes to processes? Poor leadership will grind the gears until they break in any business.
As things become more stable (or fail to stabilize, in which case you should be looking to leave), what does the future look like? Basically, figure out what happens to you after launch. Do you move on to greener pastures, do you continue maintenance for some amount of time, do you do maintenance on a basically permanent basis, or do you know? What’s the best case and worst case you could end up with and can you live with it?
If you feel there’s a future, it can be easier to survive the present. If things just drag on and refuse to change though, you’ll find yourself burned out. All of these factors get further exacerbated by the standard issues with any company (can you take vacation? Do the managers delegate responsibilities fairly? Etc.). What do you get out of the process for the better parts, the worse parts, and how is the balance? Once you can answer these, you can decide whether the juice is worth the squeeze for staying somewhere.
Image by Lubos Houska from Pixabay