How we build software
The Software Development Lifecycle (SDLC) is a formalised process to attempt to build software as cost effectively as possible based upon the requirements customers express to the technical solutions development provider.
Legacy - waterfall software project implementation
This approach experience significant pushback from software practitioners over multiple decades. Often it is termed as up-front design, up-front planning. Typically with waterfall, we define a project scope, break that scope down into requirements, assess requirements to provide estimates on how long the project will take. This gives the stakeholder a provisional estimate as to the costs of the project. The project manager will define project milestones to assess if the project is delivering to budget.
Whilst much of the software industry is quick to remove itself from the legacy waterfall SDLC to most external customers, this approach makes the most sense to most customers. If we build a house, we would want to have a pretty good estimation on how much it would cost to build. We would we would start with architectural drawings, use these to estimate materials cost, and finally determine how much time it will take for the project to complete.
There are many variations to implementation and the more common ones are Kanban and Agile SCRUM. Agile has been almost universally seen as the replacement to waterfall that it attempts to iterate faster and give more feedback to the customer quicker on the solution being implemented.
One of the biggest challenges with agile, almost every practitioner has a different way of thinking about what it sets out to achieve. In many situations the lack of a structured approach may lead to software of an inferior quality. Agile practitioners state that software quality is higher because it is suited much more to the customers' needs. Spend an hour or two on tech Twitter and we will see all manner of opinion on agile.
Really, we see agile as a set of lightweight tools and approaches to delivering software with less process. If in development team is spending too much time on the taking agile ceremonies and formalised approaches then the SDLC is not running in an agile manner.
Our opinion is that formalised agile when implementing medium sized software solutions is more expensive than Waterfall because it tends to build up technical debt. Where agile works well is when building Proof of Concept solutions, Business as Usual (BAU), and Run the Business (RTB) SDLCs.
Continuous Integration/Continuous Delivery
We will avoid defining the CI/CD SDLC in terms of a software delivery pipeline. For those wishing to outsource software development think of it more in terms of work ongoing. The emphasis is on code and data (artefacts) being built, tested and deployed, as it is released into the integration environment. Quickly after the latest build is in the integration environment it is ready to be deployed to production. In implementations of CI/CD, there can still be manual testing, and approval processes, code quality reviews - to ensure that humans are able to make decisions.
Jobs to be Done (JBDT)Jobs to be Done (JBDT)
Whilst very popular amongst thought leaders, many will be surprised to find that JBDT has been around for as long as Agile. We think of it more as an outcome based approach. We focus on a;
An example of this;
- When customers access information on my website
- I want to charge my customers
- In order to cover my costs and make profits
The example above it may seem a little trite and obvious but the powerful factor in JBDT is we don't need to focus on the actual technology first. It can be very useful to work with customers through a more declarative approach. Some may claim that this is Behavioural Driven Development (BDD) but it is not. BDD Pretty much maps a set of business requirements or user story to a coded implementation and the ability to plug testing at the same time. JBDT really helps to tease out the vision of a customer's requirements.
Our approach to developing software for our clients is therefore
We focus on iterative development which aims to build enough functionality in structure in the first phase and then later on more functionality and structure in subsequent phases until the software is good enough to meet the needs off the customer.
Where we feel that we have a relatively involved set of steps or process is required by a system we will undergo a Jobs to be Done scoping exercise. These may not be taken to the point of defining a hard set of requirements, but more based upon identifying common understanding of how the solution should work. We do this to allow us to be flexible in terms of selecting what tool and technologies will be used to talk to collaborators and partners to get a feel for the right implementation.
We may introduce agile monitoring software to help us to keep abreast of how the solution is evolving but we don't tend to focus too much on a formalised process.
What if we don't know exactly what we want? How can we manage costs?
Experience of implementing solutions working for enterprise says and small businesses gives us a pretty good idea as to select the time it takes to implement software solutions. To get a feel for this we often advise companies to look on job websites where software development contractors are needed. We typically see contracts running from 12 weeks six months to one year and often these contracts are rolling. It may be possible to see that these projects are hiring for several developers, business analysts, and testers.
We rarely engage business analysts and project managers to reduce the amount of duplicated work translating requirements from one area of expertise to another. This reduces cost and increases development time.
To help manage your costs, try to come up with a basic set of requirements and we can undertake a scoping exercise where we charge a small fee just to help you get more clarity on your requirements.