The term Software Development Life Cycle is one that doesn’t need much introductions, it is simple to comprehend in quite a straightforward way. Unfortunately however, this simplicity does not extend to real world applications of SDLC, a process so convoluted and error prone that there isn’t a single company in the world today that doesn’t suffer in the production outputs because of it.. This quick review will lay out the main issues companies face with the management of the software development life cycle as they implement it today, as well as explore some of the available solutions for each one of them.‍

Stage 1 of the life cycle is planning, which means understanding the requirements as set out by the client, and transcribing them into a general architecture for each and every feature. The workload is then divided among team members according to the working methodology used by the company. This is normally done by drawing the ideas on a whiteboard (before Covid19 times) or by using an interactive drawing tool such as miro.com.

The problem: The architecture loses its context the second dev teams start the actual coding. Why? As architectures today are drawn intuitively from a business perspective, a level of abstraction that is too far away from the code and how software products are actually built is taken, making it prone to errors and misunderstanding, setting the delivery process to failure right from the start.

The solution: Working to minimise the gap created by this level of abstraction. One way to do this is by creating more code-specific plans, laying out the precise code files and the whole organisation of the code right from the start. This in itself is problematic as some companies may find it time consuming, and that it will require a much greater team effort to bridge the gap between the different disciplines. Another way to approach this issue would be in the choice of working management tools the company uses. Tools that are designed to keep code and architecture in the same context provide their users with the perfect solution to this hurting problem.

Stage 2 of the software development life cycle as companies implement it today is the building stage. Software developers work their magic and hack together the product as they understand it from the planning stage. They are equipped with an IDE (Integrated development environment), Google and snacks and they are good to go. Work is managed with a ticketing system such as JIRA or monday.com which allow product managers to oversee as development progresses.

The problem: in addition to the problem rising from the faults of stage 1, stage 2 faces the problem of a lack of control. As product managers and business developers usually aren’t coders, they struggle to manage the development of their product and provide transparency to the client as required. This creates a high-demand low-control environment which has been shown to increase levels of stress and induce burnout. To overcome this, managers schedule more and more exhausting meetings in the hope to get a better sense of what’s going on and thus increase their sense of control.

The solution: Transparency should be incorporated in the development process. How? One way to achieve this transparency is by creating a common language interdisciplinary teams can follow and communicate through. This can be done by frequent updates (such as daily meetings) or by incorporating a tool that gives them this transparency. Such tools will combine the logical unit (code) with its business context, and allow non technical professionals to follow and understand features as they are being developed.

‍

In stage 3, R&D teams test the feature they just built in stage 2. This is done in an interdisciplinary fashion which includes QA engineers and product managers as well as the software engineering team. To achieve the goals of this stage, which is finding bugs and security breaches, these teams use a wide variety of tools; IDEs, debuggers, loggers to name a few. Many agree this is the most painful and taxing stage of the SDLC.

The problem: Going over thousands of lines of code, logs and errors is a long and complicated task, which takes a lot of time and costs a lot of money, delays delivery and increases burnout of all parties involved. Surveys show that engineers spend only 25% of their time writing code, while 75% is wasted on debugging and meetings. As stated in stage 2, levels of abstraction create a gap between the code and the business. The logs create yet another layer of abstraction a developer has to make sense of. In addition, more often than not, this also involves going over code written by another team member, which even when strict styling guidelines are enforced, is a long and taxing process in which no developer can find and fix all bugs, especially not quickly enough to meet delivery deadlines.

The solution: Logs should be inline with their code and business context. Using an IDE which not only allows developers to code without the separation of context from the business flow and clients’ demands, but also includes the logs as a part of the logical units, where they belong, thus saving time and effort understanding what exactly happens when a bug occurs. Fixing the bug is then made simple because it is not detached from its overall context. Products that offer bug tracking in real time, like bugsnag.com for example, provide immediate insight and help R&D teams to combat stage 3’s biggest problem.

‍

The last stage of the software development cycle is deployment and maintenance. This involves deployment and version control across different environments; staging, development, testing and production. The different environments correspond mostly with stages 2 and 3 of the SDLC, as every single feature has to go through testing in all four environments in order to be released to the clients (or the public).

The problem: Management of the codebase across different environments is an intricate craft which, as done today, leads to problems with versioning and troubleshooting. The idea of separate environments originated from the need to prevent bugs from being released to production systems as it requires R&D teams to double and triple check their work. Unfortunately, this idea only partially achieved the purpose for which it was designed, and mostly adds to the complexity of developing and maintaining software products.

The solution: Version control done right, allows to easily differentiate between the different versions of the code, inline with its business context and execution environment. Being able to navigate across different versions of the same feature, attached to its business use, allows for quick debugging, easy and cost effective maintenance and even improves customer support services, bespoke to each and every user.

The four stages of the software development life cycle (SDLC), while providing a clear pathway for innovation and production of new software systems, are not without faults as companies today try to cope with the intrinsic issues rising from its implementation. Many products aim to solve these problems and some manage to do so quite well, however usually at a great cost. Choosing the right tools for a company’s SDLC will set the tone for the rest of that company’s life cycle, its products and eventually how they serve their clients.