The 4 Phases: Understanding the Software Life Cycle
Software development has four main phases: development, in-production/growth, maintenance, and sunsetting.
Development
During development, we should focus on making fast progress. It doesn’t matter what color a button initially has and whether it’s placed 1 pixel to the left or the right.
We need feedback from future users about the workflow we implement and verify the most important use cases.
The mistakes we make here aren’t as expensive to fix. We probably don’t need to review every line we write because there is a big chance it won’t make it to the final product.
Does that mean we shouldn’t care about code quality? No.
Code quality is always important. We need to keep it simple and maintainable. We just don’t need the same level of polish a production app might require. Again, the goal is to make fast progress and gain quick feedback.
Most developers are thrilled to work on greenfield projects because they can move fast and aren’t held back by a pile of 1000+ lines of code files, and nobody knows what they do.
However, greenfield development comes with its challenges. You probably make more technology and architecture decisions than in other phases. Those activities require a different skill set. I believe greenfield development requires experience to get it good enough on your first try.
It’s not an exception that a team struggles to make the application work the first time and decides to rewrite big parts of the system all over again before going into production. Those situations cost a lot of money.
In Production/Growth
The first version of the application has been deployed, and we need to add additional features or improve existing features.
First, every change we make will affect in-production use cases. Therefore, we must be careful not to remove necessary tools and processes.
However, we should never be afraid to touch code that needs to be fixed or features that need to be improved. Just be cautious about how you communicate with your users/customers. Letting them know about future updates in advance will work wonders.
Database updates or other changes affecting the whole system might require more planning than during the development of the application.
We also need security measures, monitoring, and proper authentication in place when deploying to production.
Code reviews are a great tool to ensure code quality and knowledge transfer within your team. You want to ensure you can keep maintaining and developing the application. For example, if you experience changes in your team (structure).
Maintenance
At some inevitable point, your application won’t require new features.
Either the software perfectly works for a given use case, and that use case doesn’t change, or money gets assigned to other projects for various reasons.
However, you will still be responsible for keeping the lights on. The odd bug fix or stability improvement will still be required. Security patches and other period work are included.
There is not a lot of innovation going on. Most developers don’t like working on applications in maintenance. If you’re at the beginning of your career, you might not have the luxury to ask for a transfer to another area.
However, with knowledge of the situation, you can do a great job working on the app and, therefore, recommend yourself for other projects that need great developers.
On the upside, this phase probably has the most relaxed atmosphere. There is no pressure to deliver features, no sudden priority shifts, etc. You shouldn’t be expected to work longer shifts or to skip holidays. For some developers, that’s all they want.
Sunsetting
At some point, even maintaining the application is too much to ask. Maybe the company is working on a solution to replace your application or is already running a new system.
It’s your job to help migrate existing users/customers/data into the new system without leaving people hanging or causing a financial disaster.
This phase can be challenging and stressful if you face clueless managers. In general, phases like this should be clearly planned, and the transition should be executed like a military operation.
If you like following a plan that is 97% guaranteed not to change, you’ll love being part of this phase.
Conclusion
Of course, there are other faces in overall software development, such as preplanning, winning a project, or a general requirements engineering phase. It all depends on details, such as how the project is structured.
However, today, I wanted to focus on the view of a software developer and their involvement in the process.
Which of those four phases suits you best? Are you currently working on a project that fits your preferred phase in the software’s life cycle?
PREMIUM CONTENT
