If you have a software project you want to take on, or if you’re doing development on a continual basis and not getting the results you hoped for, you may be tempted to try doing some basic research on how best to tackle the issue. Prepare to be overwhelmed.
So what’s the best way to create software? Careful now—just asking this question will get you flagged as a know-nothing. The question you must first ask is: What’s the best way to talk about software development?
To your question about the best approach to building applications, you may expect an answer like “agile,” or “scrum,” or “DevOps.” But these terms have been worn smooth through overuse. (Damn marketing people.) Obviously, there’s no one word, or even one playbook, that can guide you to the answer, and there are plenty of people bandying the words about without really appreciating their foundational values, principles, or practices.
The next question many businesses that have some experience with software development often have is: “How do I make my agile—or scrum, or DevOps—project more likely to succeed?” Now we’re getting closer to a more fruitful discussion. Now we’re prepared to get away from the buzzy terms and try to get at the underlying factors that will play an outsized role in determining whether or not your development efforts succeed.
You can say it’s important for your development projects to be agile, but what’s the underlying principle that makes agile approaches so effective. There are a few. But perhaps the most foundational of them is the importance of cutting down the time separating effort from feedback.
The worst-case scenario has you gathering requirements, disappearing for months to build the entire application, and then releasing it to the clients, who either like it or don’t. That’s the old waterfall strategy that led to astronomical rates of project failure. Agile methodologies like scrum take on development projects iteratively, incorporating feedback from clients—or someone representing them—as part of each iteration.
At the conclusion of each development cycle (or sprint), the team should ideally have some feature to demo—a functional unit designed to deliver some tangible business value. This provides an opportunity for getting some invaluable feedback from the client side. Incorporating this input from users is critical for creating an application that delivers real business value—as opposed to simply fulfilling a list of technical requirements drawn up before the details of the project were fully worked out.
But the feedback loop can be shortened even further, all the way down to functional units of code. Many of the most advanced development teams use a process called Test-Driven Development (TDD), which has them coding a test for the unit they’re working on, and then coding for the unit’s actual functionality to see if it passes the test.
One of the advantages of TDD is that it encourages you to take the simplest, most direct route to the functionality you’re after. There’s no such thing as perfect code, but focusing on one function at a time helps you write code without extraneous elements or unnecessary connections. This cleaner code is much easier to work with when you’re making updates or adding new parts.
You can also think of TDD as a really short feedback cycle. What you’re after is code that supports the functioning of a software feature that delivers value to the company. The most direct route to that functionality usually leads to the most valuable features, and it also leads to code that will be resilient, manageable, and scalable. TDD, which often means the developer literally has a red light that turns green when the test criteria are met, provides some of the quickest feedback possible. So the developer stays focused and creates cleaner code.
You may also encounter the term BDD, or Behavioral-Driven Development. This is a practice that grew out of TDD and Acceptance Test-Driven Development. For our purposes here, you really don’t need to know the nuances of these practices. More important is that they all operate on the principle of the shortened feedback loop.
Today, even developers working on internal-facing software for enterprises are tasked with making constant improvements. Your business’s day-to-day operations are so intricately tied to technology that to remain competitive you have no choice but to always be adopting—or developing—the most impactful tools and practices. And it has to be an ongoing process.
Competition for positions near the leading edge of technology and delivering value to users is even more intense when it comes to consumer-facing software. That’s why companies like Google, Netflix, and Bing (i.e. Microsoft) practice continuous deployment. One of the innovations that has made continuous development possible is the joining together of what used to be two different teams with two different objectives: the developers and the operations people. So now we’re in the territory known as DevOps.
Developers are of course the people writing the code and making the software. These are the ones you’ll hear talking about scrum and product backlogs and sprint retrospectives—all the methods for making development projects more agile. But who are the people who make up the operations half of the DevOps equation?
Operations folk are your System Administrators, Network Administrators, and Security Experts. Here’s a breakdown of what they do:
Traditionally, the developers would create the software, test it, and then toss it over a proverbial wall to the operations people. Operations would in turn deploy the software to users and make sure it keeps working. This stepwise process sounds a bit like an assembly line; it’s very waterfall. The question is how do you make the whole process agile, not just the development side. How do you make it agile all the way down?
The first thing you do is knock down the wall separating the two sides. Now the developers get help designing software that’s maintainable, and the operations people get help with automating various aspects of that maintenance (coding software that tests and maintains the other software).
The importance of cross-functional teams is one of the main principles of the agile philosophy. But another way of looking at DevOps is that it offers members of the team—both the devs and the ops—more immediate feedback, so it’s another way of shortening the cycle. You no longer have to toss something over a wall and wait for word to come back about how well it’s working. Both sides are now working side by side, in the same room (figuratively speaking anyway).
Shortening the feedback loop assumes you have some goal you can measure your progress toward. Each unit of software needs to function, and it needs to function alongside all the other units, but the ultimate purpose isn’t any particular functionality. The ultimate purpose is that it provides value to the client’s business, either by helping them perform tasks more efficiently or by helping them engage their own customers more deeply.
The problem with traditional waterfall strategies is that they force companies to conceive of the application all at once, all before testing a single approach to addressing an issue. You would draw up a static list of requirements, and then you’d proceed to build whatever you dreamed up.
Obviously, this means a really long feedback cycle. But the really fatal drawback is that this reliance on upfront design forces the team to focus on technical implementation instead of on the delivery of value. Saying a feature works the way it was described in the original design is not the same as saying it works to address some challenge the user is facing.
The goal of delivering business value, the extension of agility, and the shortening of feedback cycles—these are the principles that currently drive the top development companies, distinguishing them from their more middling competitors. They’re also what you’ll want to focus on as you go about trying to improve your own development processes.
Want to learn more about agile software development? Check out these episodes of our podcast: