The way that we build software has changed dramatically in recent years. Modern Application Development (MAD) and cloud-native development practices are essential for any organization that wants to remain competitive. MAD enables software-driving entities to adapt quickly and efficiently to the dynamic consumer marketplace. So what does this mean for software engineers and other technology practitioners, and how do we ensure that we have the right tools and training for this new frontier? This article will explore Modern Application Development, discussing the driving forces behind this new approach, the benefits that it offers your organization, and the risks associated with a failure to embrace it.
Traditional software development is a time-consuming and unpredictable approach to building applications and solutions. It takes time to gather all the requirements and develop a comprehensive design and development plan. Only once that work is complete can you begin development. Even with a careful and realistic plan, things seldom stay on schedule. If the development team achieves its goal, the code must pass through QA, security, performance testing, and finally to the operations team for deployment.
In a world with a highly dynamic consumer base and changing landscapes, time isn’t a luxury that we have, especially if it’s tied to an unpredictable design, development, and delivery model.
In stark contrast to traditional development, MAD is about delivering value quickly and efficiently to the end-user. If requirements or customer needs change, MAD allows you to change with them and serve your consumers in the best way possible.
Adopting the MAD approach to software development can be challenging, and it requires your organization to commit to a completely different approach to software development and embrace a cultural change. Let’s look at some of the changes you’ll need to make for MAD to succeed.
Consolidation and Ownership
MAD development teams own their software and are empowered to decide how their applications and services are built and deployed. They also own the support for those applications. This approach requires well-trained and innovative engineers, and it tends to bring out the best in those engineers.
A New Architecture
MAD works best when paired with an architecture that is fault-tolerant, scalable, and loosely coupled. A microservices-based architecture works well for MAD, as does a cloud-native architecture. Many people confuse or use the term cloud-native synonymously with MAD. While cloud-native architecture and principles are a component of MAD, however, MAD principles extend far beyond cloud-native architecture and engineering.
MAD is fast and innovative. When an organization commits to MAD, it’ll need to invest in building the right processes and habits. Then, it’ll accelerate to a point where it can consistently deliver software faster and with higher quality than ever before. That acceleration comes from short development cycles and learning from mistakes. If engineers are experimenting and pushing beyond previous limits, they’ll make mistakes. Learning from those mistakes and improving based on that knowledge makes MAD an exceptional and adaptive approach.
If you’re risk-averse, the previous paragraph might have you feeling a little uneasy about this new approach. Think of it like comparing highly-effective software engineers with Olympic-level snowboarders. An elite snowboard athlete doesn’t become the best in the world by practicing within their comfort zone. They have to push boundaries and limits, and sometimes they crash and fall. However, helmets, pads, and other safety equipment limit the damage and allow them to practice extreme tricks safely.
MAD entails mistakes and risks, but it also recommends guardrails and safety nets to prevent your mistakes from escaping into the wild. Static code analysis, security scans, AI-supported deployment tools, and unit, integration, and performance tests allow you to experiment safely and help to limit the blast radius of mistakes when they happen. It doesn’t mean that you can be careless, but it lets you push the limits of your technology and experiment without catastrophic consequences.
You could also decide not to adopt MAD. You’ll avoid the pain associated with change, and you won’t incur the expense of investing in new tools, processes, and training to create an environment where MAD can thrive. But not taking the risk may be the riskiest decision you could make. As technology accelerates and our consumers continue to expect more and more from our applications and services, traditional software development methods won’t be able to keep up. From within the safe confines of our traditional ways, we’ll observe the world change, and suddenly it’ll be too late; we’ll be unable to keep up and we will ultimately fail.
If MAD sounds like something you’d like to explore, or if you’re already experimenting with MAD and would like to accelerate your learning and proficiency, the internet has a wealth of resources where you can learn more and engage with experts in this field. An excellent place to start is the Modern Application Development resources page on the Checkmarx website. You can learn more about embracing MAD safely with great tools and recommendations.
Mike Mackrory is a Global citizen who has settled down in the Pacific Northwest – for now. By day he works as an Engineer Manager for a DevOps team, and by night he writes and tinkers with other technology projects. When he’s not tapping on the keys, he can be found trail-running, hiking and exploring both the urban and the rural landscape with his kids. Always happy to help out another developer, he has a definite preference for helping those who bring gifts of gourmet donuts, craft beer and/or Single-malt Scotch.