Software development lifecycle: understanding how products get built

Context

In this post, I will walk through how I researched the current vendor marketplace for the software development experience area. I’ll also write about how I view the overall Software Development Lifecycle (SDLC). We’ll get into how I came up with a list of companies, and what products they offer that target various requirements.

By the end of this post, you will have an insight into the software building process, with emphasis on the actual development area.

The next posts will cover how these companies fit into the SDLC, and if it makes sense for a new project to be spun up, targeting a specific problem space.

Background

We have products like Google Docs, Sheets, etc and all the tools in Office 365 for collaboration, and it is becoming increasingly rare to see documents, etc get written on software running on a local laptop. Similarly, when developing software, you can rent computers from multiple cloud service providers but deciding between the options presented on the UI, is a lot like walking into a restaurant and the waiter asking you what kind of flour you want in your bread!

There are some companies that offer managed experiences, but those offer a subset of the functionalities and operate in a more constrained environment.

Why is it important to optimize the software development process?

Developer productivity is important not only to improve engineering and product outcomes, but also for developer satisfaction. It’s a waste of resources if a developer isn’t able to spend a majority (if not 100%) of their time working on actual products, instead of having to deal with ancillary systems. It must be noted that developer tools, etc are not the only major factors that impact developer productivity, although that is the focus of this post [1].

Engineers spend a lot of time in the development phase (duh!) of the SDLC (more on that in the next section). From a high-level, these are the general phases:

• make a one-time decision that may have lasting repercussions (eg: choice of language, framework, spaces v tabs, etc),
• choose infrastructure on which software is written (at a smaller scale, this is done completely on the local laptop which might have access to the production/pre-production network; at a larger scale, the previous approach starts to show stress due to: amount of code, supplementary software running on device, inability to scale compute power, etc),
• testing using various strategies; depending on the product being built, the developer might choose to write unit, component or integration tests, which might or might not need access to production systems,
• configuring the components used to roll out the software in an integrated developer console of some sort, and choosing dependent subsystems,
• rolling out general configuration/tools and having software run on the device to satisfy compliance/regulatory/security requirements — usually rolled out transparently to the end-user; traditionally, a lot of things fall into this bucket, and they have a detrimental impact on developer productivity.

Optimizations at the framework-level usually help standardize coding practices at a company, and help make large-scale code refactors. While there are quite a few offerings in open-source software (OSS) (java/dropwizard, python/tornado, go/gorilla, uber-go/fx), companies usually wrap them in their own flavors. Therefore, it can be quite hard for a SaaS solution in this space since they’d usually offer a generalized solution.

Development on the local computer is very fast for smaller companies and rapid prototyping, but it starts to break apart as the company scales up. The industry has moved towards microservices; smaller companies generally start their journey by using micro-repositories to store source code (larger corporations have begun migrating to monolithic repositories, to back their microservice architectures). Usually, every repository makes some assumptions on the state of the underlying host, and as a result, working across multiple repositories becomes quite challenging, even before the actual building process has started (require multiple versions of the same language, not working with the latest version of an operating system, etc)!

More importantly, dissatisfaction with the local development environment ranks in the top 5 areas for improvement in Developer Experience NPS in companies with 200+ engineers.

Usually, a new laptop alleviates the problem (large, aging codebase, multiple requirements competing for local resources, etc), but it becomes infeasible to keep switching laptops in anything less than ~1 year.

Every new variable involved in the software development process adds complexity. There has been a push (and subsequent success) towards homogenizing the production infrastructure (containerization, workload orchestration, etc), but similar movements have only recently commenced on the development workflow side (most are still on the fringe, and as a result, not very enterprise-friendly). The direction is towards writing software in the web browser (GitHub Codespaces, CodeSandbox, Paperspace, etc), but very few developers in the larger companies seem to be open to this cultural shift of coding in a browser (they prefer their IDEs and existing workflows, and forcing that paradigm shift seems unnecessary at this time). This is the area of focus for Devinfra.

Depending on the system/feature being built, various testing strategies can be employed — you can either test against sample {in, out}put to the system, or test how an entire component (eg: a full handler, end-to-end, including the persistence layer) behaves, or test how something behaves when it makes network calls to downstream systems. The developer makes the decision and can choose from a set of frameworks (py.test, junit, go/testing) and locally-run infrastructure (docker-compose, vagrant); this is largely OSS.

In the CI/CD stage, the focus is usually on integration testing, building containers, testing for reliability as a result of rolling out this new change. There is quite a large presence in the SaaS space for this stage (Circle CI, Armory/Spinnaker, HashiCorp Waypoint, Jenkins, Buildkite). Even the larger companies usually use these SaaS providers, although a small number of companies choose to build their own (when there are multiple internally-hosted infrastructure dependencies).

Over the last few years, the risk from insider threat attacks has gone up, as has various compliance/privacy/regulatory/security requirements. There are quite a few SaaS companies (Crowdstrike, SentinelOne, Fortinet, Palo Alto Networks, McAfee, Carbon Black, FireEye, Cylance) that have endpoint protection software. General configuration management on laptops that have the model of executing changes on a local laptop, remotely (Chef, Puppet, SaltStack, potentially Terraform).

How do we begin to map out the space?

Over the last 5 years, I have started to think about the SDLC as having the following stages:

1. Ideation (think about why you’re building, who you’re building for, what it will solve, and how you scope it out)
2. Development (exploratory phase of integrating with other systems, build the product, write tests, get local secrets, link things w/ issue tracking tools, etc)
3. Continuous integration/deployment (get code reviewed/landed, run integration test suite since it can get quite cumbersome to run locally, build container images, perform security scanning and notify deployment pipelines)
4. Production (answer questions like where will the container run, figure out appropriate deployment strategies at the overall company level, think about logs/metrics collection, etc)
5. Maintenance (keep the product running/supported, make iterative changes that lead back into the Ideation stage).

Concepts of access controls, privacy, data custodian requirements etc impact each of these stages so I haven’t called them out explicitly.

Stages of SDLC

Now that we have a rough way of breaking the SDLC up into stages, let’s scope out the set of companies targeting each space, alongwith the problems they are attempting to solve. There’s no single source of truth that you can go to, to see which companies focus on the “Build Stage of the CI/CD”, or which companies are built around certain area of the SDLC — yes, Google can get you started, but I often ran into cases where someone would mention a certain company that I hadn’t heard of before. Okay, let’s fix this.

This would end up being the starting point of my search:

• targeted search patterns on Google
• posts related to development on Hacker News {example}
• new announcements on Product Hunt {example}
• basic searches on Kickstarter and Indiegogo

The next 2 I found quite interesting (and helpful):

• Crunchbase query builder
• going through recent investments made by some of the VCs I track (this space seems to be picking up steam recently, so I focused on the last ~1 year)

This approach yielded the following data:

• set of companies operating in each stage of the SDLC (not a 100% comprehensive, but a solid start)
• set of companies that have recently raised capital (varying # of employees across the various financing rounds); talked to employees at these companies which influenced the kind of companies that would benefit for a managed development experience
• improved set of VC firms; also gives an idea about which partners focus on SaaS companies in the “building” phases.

What matters?

Based on the research, I came up with a set of requirements/problem areas. In order to be purposeful about the problem we are solving and how Devinfra can be of value to an organization (should also be helpful in defining a marketing/sales strategy), these requirements need to be broken down into themes.

Although this project can have various benefits for an enterprise, a developer tool needs to have bottom-up adoption/engagement in order for it to be successful. But, the revenue generation side will be driven by enterprise adoption. More on that in future posts.

In general, we find that developer-focused requirements tend to go against enterprise-focused requirements. While we want to fundamentally change that (by moving from either/or, to having both), we’ll use it here due to familiarity. Security/compliance goals are often met by instrumenting environments with a variety of tooling — I am not certain we’ll be able to get away from this entirely, but this can also benefit massively from a set of seamless integrations, paired with the flexibility of the cloud.

The following visualization shows how various requirements map across the quadrants I referenced in the previous paragraph.

Conclusion

We have a why/how/what describing why the current world of software development isn’t that great, and imagining a future state.

The next post will dig further into how we focus on the development state of the SDLC, what we believe the development process at an enterprise will look like a few years from now, and how we trace the path back to where we stand today. Please consider following us, as we embark on this journey!