Software Development: Moving Away From Expensive Sequential Workflows

“Software will eat the world,” said Marc Andreessen in 2011. He predicted software would revolutionize and change the way industries function. Which by the way happened to be true. The question here is, that software development has disrupted the way the world works but not its own processes, why? There is no doubt software development processes have come a long way, but they are still the same at their core. The software development workflows are sequential, time-consuming, and full of painful backsteps. What if the software development process was parallelized?

Let’s discuss what I mean by this, but let me walk you through the basics first.

What is software development?

Software development is the process of building computer programs and applications. It all starts with careful planning and design, followed by writing the actual code. Software developers use various programming languages and frameworks to write the code that instructs computers to perform specific tasks. After that software testing is done to detect and fix any errors or bugs. Once it is stable, the software is reviewed and built. It moves through different stages, including quality assurance and staging, before going live. In essence, software development is the driving force behind the wide range of applications we come across from mobile games to complex enterprise software systems.

Software development process:

There are certain stages in the software development life cycle. We will discuss what they are and then later talk about how different development models handle these stages. The prerequisites of software development are carrying out market research to

• Check the viability of product
• Define the project goals and developer tasks
• Design software architecture

1. Code

After you are done with the above things, the actual process of writing the code and burning your application to life starts.

1. Test

This implies local testing after writing the code, to identify and rectify any issues, bugs, or vulnerabilities within the software. This phase ensures that the program functions as intended and is free of errors.

1. Review

The review phase involves a critical examination of the code and the overall software structure. It often includes peer reviews or code inspections to enhance code quality and maintainability.

1. Build

The build stage means building your code into executable files or packages that can be deployed on various platforms. This process transforms the code into a usable software application.

1. Stage

Software applications are deployed in staging environments to further test and evaluate them. Staging is done to ensure a smooth transition into the production environment.

1. QA

Quality assurance is an ongoing process throughout software development. It focuses on maintaining the quality, reliability, and performance of the software. It makes sure the software application meets all required standards and specifications.

1. Live

This is the production environment where software is finally deployed and made available to end-users or customers. In the “live” phase users can interact with and benefit from the software's functionality.

What do typical software development processes look like?

Typical software development processes can take several forms. Let’s discuss two of the main software development methodologies to understand the process better.

1. Waterfall Model

This methodology takes on a sequential and linear approach towards software development. It typically includes distinct phases such as requirements gathering, design, implementation, testing, deployment, and maintenance. Each phase must be completed before moving to the next. This is what makes it difficult to make any changes to the project once a phase is completed.

1. DTAP Model

The DTAP (Development, Test, Acceptance, Production) model is another framework in software development and deployment. It involves a sequential progression of environments, starting with Development, where code is created and tested. It is then followed by testing and acceptance for user validation. The final stage is production, which is the live environment. This approach ensures that software is thoroughly vetted before reaching end-users, reducing the risk of errors in production. However, the process can be challenging due to the potential need for backsteps, where issues discovered in later stages may require revisiting earlier ones.

1. Iterative Model

The other common approach towards software development is iterative or incremental. This approach involves breaking the project into smaller parts or iterations. Each iteration goes through the entire development cycle, which allows for incremental improvements. This approach provides constant feedback and hence more room for adaptability. However, the issue of repetition stays the same although it is a bit faster than the waterfall model.

All of these software development models are linear with possible repetitions and backsteps.

The Development Process

The typical software development process follows almost the same steps irrespective of the model used. It starts with a developer writing the code, which is then pushed to a remote repository. It then gets deployed to some QA instance or preview environment. Then it undergoes testing and if any bugs are found the developer has to check out that branch locally again and fix bugs. The same cycle from step one gets repeated again. It is like tracing back your steps in sand and then redoing everything, which definitely takes a lot of time and seems counterproductive. This cycle of code refinement and retesting may iterate until the software is bug-free and ready for deployment.

Another highlight of the process is how different phases of the software development cycle are handled typically. There are two different departments handling development and operations separately.

Challenges with typical process

While the software development process works, it carries certain challenges. The iterative nature of development, with repeated code fixes and retesting, can lead to increased development time and potential delays in project completion. This means you end up with higher costs and lose a substantial amount of time going back and forth.

Additionally, the problem gets even bigger when you are working on large scales or in big companies. People are usually part of smaller teams in such instances and all the teams have a different version of the above-discussed software development process in place. It means people cannot easily switch between projects because of the lack of knowledge of all the different kinds of processes.

The cherry on top here is having separate development and operation teams. The divided functionality leads to inefficiencies, communication barriers, and slower deployments, due to a lack of collaboration and coordination between the two teams. This is what we commonly call “DevOps Silos”.

Each bug identification and rectification cycle demands additional effort from developers, resulting in a slower go-to-market speed. It means two things: one, that you will be solving the wrong problems. What that means is the current software world is changing very fast, you have to act fast to meet the demand. If it takes you long enough, by the time your product goes to market it won’t be relevant or way behind what the market demands. Secondly, the later you find a bug, the more it costs you. It is called the defect cost multiplier. For example, catching and rectifying a bug that has already affected the end user will cost you more than the one caught at an early stage. Both because of the loss of trust and having to go through all the backsteps again. Here is a graphical representation of the phenomena.

Defect Cost Multiplie for

On top of that, after all this, you need to have DevOps engineers to deploy the code and servers to host that code, further putting a money strain. All this racks up pretty quickly, resulting in a slow software development process with high resource and operational costs. Most of the solutions to improve the dev processes today require a lot of redundant computing resources (i.e. preview deployments etc.) - this can become unmanageable and expensive for larger teams. For example, if we talk about Codesphere, our dev team already has ~700 branches and 200+ pull requests. Each of them requires resources to run independent versions of codesphere. These numbers grow even bigger as the size of the team grows. Without on-demand resource allocation, this makes preview deployments too expensive.

Trends in Software Development Processes

The history of software development has witnessed a dynamic evolution regarding methodologies. The waterfall model is a rather old and linear way of handling things that originated in the 1970s. Software development has evolved and passed through many stages since. In the early nineties, the term continuous integration was first coined which later emerged as CI/CD, an approach focusing on automating the build, testing, and deployment processes to ensure quicker, more reliable software delivery. In the meanwhile, software development in general leaned towards the Agile approach as opposed to the waterfall model. Agile emphasizes flexibility, collaboration, and continuous iteration, allowing for more adaptive development.

There have been several other micro trends or approaches like serverless introduced by Amazon, which gained popularity in the last decade. It introduced cloud-based computing platforms that abstracted server management. However, it was later proved to not be as revolutionary as it was once thought to be. Recently, Amazon came out to say it became unsustainable cost-wise when used on a larger scale.

Another, approach that got popular at the same time was using a microservices architecture. It implies breaking down monolithic applications into smaller, independent services. This modular approach tries to simplify development, scalability, and maintenance. It also fosters flexibility in deploying only the required services.

The historical trajectory of software development shows a shift in approach from rigid, linear models to more adaptable and, automated models. This brings us to the question, what does the future hold for software development?

Interview with Codesphere Founders

We interviewed Codesphere founders to ask them how they handled the software development process at Codesphere. We also asked them to reflect on their thoughts about the software development process in the next 5 years.

Each topic is followed by a question for Roman on practical tips on how we handle this internally and Elias for an outlook into the future.

Let’s see what they have to say about it.

.tg {border-collapse:collapse;border-spacing:0;}
.tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px;
overflow:hidden;padding:10px 5px;word-break:normal;}
.tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px;
font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;}
.tg .tg-0pky{border-color:inherit;text-align:left;vertical-align:top}

| | Elias: Elias Groll is the CEO of Codesphere. He started coding before he turned 10. At 15, he started studying Computer Science, taking university classes while still in high school. Elias then joined Google as an employee in 2019. Not being impressed by the technology there he co-founded Codesphere. |
| | Roman Forlov: A boy who started working in hospitality at the age of 14, taught himself computer science at the age of 21 while working at a bar. Co-founded a startup, failed, and then co-founded codesphere at the age of 25 to make the DevOps experience better and more accessible to everyone. |

Elias: Elias Groll is the CEO of Codesphere. He started coding before he turned 10. At 15, he started studying Computer Science, and taking university classes while still in high school. Elias then joined Google as an employee in 2019. Not being impressed by the technology there he co-founded Codesphere.

Roman Forlov: A boy who started working in hospitality at the age of 14, taught himself computer science at the age of 21 while working at a bar. He co-founded Codesphere at the age of 25 to make the DevOps experience better and more accessible to everyone.

*Painful backsteps: “Repeated code fixes and retesting, can lead to increased development time and potential delays in project completion” *

• Roman: how do we tackle this challenge at Codesphere internally?
  • At Codesphere, we write automated tests, which allows us to move faster as we have higher confidence in making changes to the code base - if a change breaks something, we’ll catch and fix it early thanks to the existing tests.
• Elias: What will this process look like in the future?
  • Parallelization of process steps is key for improving the time to market and luckily that is increasingly easy to do in practice. Instead of sequential steps that require starting back at step one if issues need to be fixed with tools like Codesphere developers will be able to make code changes in any step of the process. This makes dev teams much faster!

Separate Dev and Ops teams: “Companies have challenges with separated development and ops teams, what we commonly call “DevOps Silos”.”

• Roman: How are our teams at Codesphere positioned to avoid this?
  • Collaboration is key to a productive company. We avoid silos by having cross-functional teams and regular syncs between departments. On top of that, we often work on projects together.
  • Additionally, our teams rotate on important functions like weekly QA & BuildCop (making sure CI/CD runs smoothly)
• Elias: 5 years from now - will there still be DevOps Silos or will the problem shift elsewhere?
  • We are already seeing a shift towards a unified function where the developers are more and more enabled to manage their own infrastructure eliminating the potential for silos. Developers will be able to do much more with the same amount of resources and that’s a very exciting development! One thing that will remain challenging in the future is making sure business use cases (which might actually still increase in complexity) and development are aligned - the time freed up on the infrastructure side will be very helpful here.

*Non-streamlined dev processes: “People are usually organized in smaller teams and the individual teams have different versions of the software development process, making it hard to switch individuals between teams and creating knowledge silos” *

• Roman: What guidelines and rules do we set internally to avoid discrepancies between our software teams?
  • All teams adhere to the company-wide knowledge base where each engineer can contribute.
• Elias: What is your take on - a universally streamlined dev process that any company (of any size and vertical) can follow sounds like it is too good to be true?
  • Codesphere doesn’t force everyone onto the same process! The key to a universally adaptable process is to maintain flexibility and extensibility without increasing the complexity to an unmanageable level. Codesphere’s standardization in software operations sets industry-leading standards that will make your teams faster - if your specifics require a custom change though that’s doable and envisioned. For enterprises, we have technical account managers & experts that can help.

Infrastructure costs: “A lot of the solutions to improve development speed (i.e. preview deployments) require high amounts of computing resources which gets expensive as companies grow”

• Roman: How do we ensure efficient computing consumption during our dev processes?
  • We only run what absolutely needs to and as long as it needs to, thus avoiding unnecessary costs coming from deployments that run unused or have excessive resources.
• Elias: Codesphere is working on an on-demand infrastructure innovation that will eliminate this altogether. Can you give a rough idea of where we stand today compared to how much improvement we still expect over the next few years?
  • Our patent-pending fast cold-starting on-demand infrastructure can already achieve a 90% cost reduction for preview deployments and low traffic, high compute use cases like internal LLMs. Today cold starts take a few seconds but with the patented technology we believe we can get this down to milliseconds which will broaden the range of use cases that can profit from this on-demand infrastructure - this will be nothing short of game-changing. Imagine you can vertically (server size) and horizontally (amount of servers serving parallel requests) change the compute in split seconds - you can go from overprovisioning and 90% of resources being unused 90% of the time to very efficient underprovisioning that scales with demand in real-time.

Wrap-up

In summary, while software development has revolutionized industries, its own processes remain outdated and prone to challenges. Traditional sequential workflows, like the Waterfall and Iterative models, lead to extended timelines and increased costs.

Looking ahead, we anticipate a more parallel approach to software development. The optimization of resource utilization and innovations in on-demand infrastructure will drive down operational costs and increase adaptability. The industry is on the verge of a significant transformation, resulting in faster, more efficient, and adaptable software development processes.

What are your thoughts on the current state of the software development process and the innovations that might come in next five years?