This morning I had the opportunity to chat with software engineers and data scientists at the AI Dev World Conference on a topic I just happen to be v...
Over the past 30 years, nearly everything about software engineering has changed. What was once a relatively niche part of the company such as setting up a single-page website or building a time entry app for employees — is now responsible for the thing that’s eating the world. In short, every company is a software company.
There’s been a corresponding change in the way we talk about software engineering and the way we think about software engineering. The ‘we’ refers to both technologists as well as the business stakeholders who now depend on engineering to run the business.
At Pinpoint, we talk a lot about the software pipeline because it strikes us as the most accurate way to discuss how an idea goes from a whiteboard or a business idea to a functioning application.
The industry lingo used to talk about this same idea, however, has gone through a number of iterations over the years. Let’s take a look back at a few of them.
Software Development Lifecycle (SDLC)
In the 1990s, most people in software engineering talked about the software development lifecycle, or SDLC. This was a very linear, one-way concept. Applications were born, went through some kind of testing, were deployed and used in production for a while, and then died. There were no iterations. Software was born, was used, and then went away and was replaced by something new.
This term also coincided with the very early days of enterprise software development. In the 1990s, major enterprises were starting to use software, but often only had one or two applications in actual use. By the late 1990s, however, this term had started to feel old.
Application Lifecycle Management(ALM)
By the early 2000s, application lifecycle management, or ALM, was the term most people used to talk about the same idea as SDLC. This coincided with more mainstream adoption of software — companies started having multiple distinct applications to manage, and it made sense to talk about ‘applications’ rather than just ‘software’. However, by the early 2010s, ALM was starting to sound old-fashioned, as software started to eat the world and companies became increasingly concerned not just about managing their application lifecycle, but actually developing quality software and using it to create competitive advantage.
The term that’s still nearly as ubiquitous today as when it originated is DevOps. Originally, DevOps only referred to strategies that made the handoff from development to operations less painful. Today, DevOps has expanded to includebreaking down the barriers between different engineering roles and bringing them together to work on product-oriented teams that handle development, testing and QA as well as being responsible for deploying and operating the application.
As the term DevOps has expanded in scope, a number of related terms have also crept in to popular usage.
Continuous Integration and Continuous Delivery (CI/CD)
Continuous integration and continuous delivery (CI/CD) is a subset of DevOps that refers to how software moves from the time a pull request is made and actual code starts being written to when the changes are released to the production environment. In an ideal CI/CD scenario, the entire process is automated and code changes can be deployed hundreds of times per day. In reality, only a small minority of companies have a fully mature CI/CD process in place. Others are undoubtedly working towards a more continuous delivery model, but in most cases aren’t there yet.
Value stream, or value stream management, is a term borrowed from manufacturing that has only recently been applied to software development. Whether it’s applied to creating widgets or applications, value stream management refers to creating value for the business. In a manufacturing context, this would mean managing the business assets and manufacturing pipeline and focusing on areas where the company can streamline operations and increase value.
At Pinpoint, we like to talk about the software pipeline. Thinking in terms of this manufacturing analogy allows us to apply some of the lessons from concepts like value stream management to software development, like looking for bottlenecks in the pipeline, identifying areas where things are produced too quickly, perhaps to the detriment of quality, and in generally reducing wasted effort in the creation, testing and delivery of software.
Using manufacturing analogies to talk about software development also points to a more important shift not just in vocabulary but in the role of software. Just as producing widgets used to be how companies produced value in the past, now companies create value through the creation of software. This is true even for companies that also need to manufacture goods — without cutting-edge software, those companies won’t be competitive.
Many of the other frameworks fail because the rest of the business (the CEO, Sales, Finance, etc.) is speaking a different language when asked, “How are we doing?” Using the pipeline analogy has the additional benefit of helping align engineering with their peers when speaking to performance of their organization.
Evolve Your Software Pipeline
See how your teams work, discover what’s going well, what isn’t, and how engineering can drive better outcomes. Learn more about the software pipeline metrics that Pinpoint recommends to help provide a clear and actionable view into the performance of your engineering team.
Sr. Director, Marketing
Meet Andrew. He’s our Director of Backend Engineering and is a member of Team Bolt ⚡️ who is currently working on buildi...
Meet Mike. He’s a Platform Operations Engineer here a Pinpoint and member of Team Bolt ⚡️ . who is currently working on ...