The Process to Deliver a Software or Web Application Into Production
By: Before Semicolon
Tags: JavaScript, Software Architecture, Technology, Software Engineering, Programming

I have worked for different companies which allowed me to experience different strategies when it comes to take an idea and release it to the public as a final product. Whether you are part of a small or big project, I believe any developer would benefit a lot from understanding the entire process of what it takes to deliver software or application.

Analysis

The first thing that triggers a product or software development is the idea or a solution for a specific problem. After that, you normally look at the market for existing solutions if any. If you find one you take a closer look at them to see if they lack something you can contribute to or if you can just go ahead and build something better to compete in the market.

I call this part “research the idea” and in a software development cycle it is called analysis and it is the step where you define the scope and the project itself. You measure the risks, define a timeline that will take you to the final result, define or anticipate issues or opportunities, and plan for things as well as come up with the requirements for the project. This step may even determine if the project should go forward or not as well as how.

Documentation

This phase is to come up with a way to document the project solution and requirements and it must contain everything needed during development and provide few checks: Economic, Legal, Operations, Technical, and Schedule, more or less.

You must define the costs related to the development of the project, go over copyright and patents to avoid any legal conflict around the idea and product. The delivery schedule is a big one especially if you have a sales, marketing, and social media team and they need to create content and be ready for launch to promote the product.

Design

The design phase is not just about designing the interface of the product itself but anything related to it. It can be the overall system architecture, how the data look like, where it will be stored, and how the data flows in the system. You also define the functionality of each module and all related logic as well as how these modules talk to each other and yes, you also design the interface of the software as well.

Coding

After the design phase is the coding phase where you analyze the idea the documentation, requirements, and specifications and start coding things by following a coding plan, the product schedule, timeline, and roadmap. Anything that turns out to be more complex and deviates from the original plan should be communicated. Things may change as a result.

I often see plan B being applied where you find an MVP version of the feature or the delivery and implement that and come back to it later on where you further improve the feature after much detailed research. The show must go on and it is hard to remove a wagon after a train is in motion.

The coding is done maybe by following an agile development model where features are delivered in sprints, are planned in sprint plannings, and get daily Engineer updates in daily stand-ups. The development team keeps a backlog of features and bugs to distribute among them and address them per sprint which usually takes 2 weeks.

Testing

When the code is done it is the testing phase. I am not talking about unit tests as those should happen during the coding phase whether you use a Test Driven Development technique or not. The test phase is for QA and E2E(sometimes). These tests do not happen after 100% of the things are coded. They happen as different parts are completed.

Anything that is found to be faulty or deserves improvement is sent back to be fixed by the engineers. The goal is to not introduce new features but to check that what was coded follows the requirements and does what it is supposed to do. The E2E is created to automate the user flow in a step by step pattern to mimic how the user would use the product.

Deployment

If everything is coded, tested, and seems to be right it then gets deployed but it does not mean that developers and testers job is complete. The QA then tests things in production as the production and development environments are different and again, anything found to be broken is also sent to be fixed by the developers.

At this point, the user will start interacting with the product and sometimes things come up and this is when customer support comes in. These people understand how the product works because they got trained as things were being built or at the end.

These people will guide the users, through the product in case of any problem or if the user is stuck in some issue that is preventing them from using the product where anything perceived to be a problem is turned into issues that are sent to the developer’s backlog to be checked by the engineering team and gets fixed if necessary.

The customer support may even be the developers as well. Some companies use the concept of having developers “on-call” for any user-related issues. Normally small companies do that and these engineers stay on call even during non-business hours.

Maintenance

After launch, there is the maintenance phase, the final phase of the cycle. This phase includes bug fixes like those reported after launch, software upgrades, and any new feature enhancements. The development cycle is circular so if any new thing, version, or complex update needs to be done it goes from phase 1 again until it is delivered.

Observation

One thing to notice is that the coding phase is often small. There is a lot of planning and support time dedicated to delivering a product. I worked in companies where we took 2 and a half years to deliver a product as well as others that took 3, 6, or 9 months depending on the product type. No matter the time it takes to deliver software, they all follow or try to follow a software development cycle.

Red Flag

A red flag would be a place where the coding time is the largest phase and normally these are startups that experiment, test, and come up with requirements as things are being coded and designed. These environments tend to be very stressful to work at as things may change as you are coding them, meaning, you start a sprint with a set of requirements and by the end of the sprint the design and requirements may change which may mean that the developers need to allocate extra time to address these changes.

Conclusion

It should not matter the size of the project, whether it is a side project or a freelance project. You should always try to follow a plan and get good it. The steps will narrow your focus and allow you to deliver a product in junks which will keep you on track and satisfied as you go.

I implement these steps fully or partially in my deliveries which allows me to finish a side project, give a detailed plan, pricing, and timeline for a freelance project client, communicate well with the VP, managers, and project owners at work.

Watch me code and create things by visiting beforesemicolon.com or subscribing to my YouTube channel.