The role of DevOps practices in application design
Fancy architecture diagrams and aesthetically pleasing code are nice things to have. But they don't mean much without the support of DevOps-centric design practices.
By
Darren Broemmer, Developer Evangelist at DevGraphGuest Contributor
Published: 20 May 2021
Analyzing post-development customer insights provides a straightforward way to drive the development of new features and address problems with what you've already released. The challenge, however, is to take this one step further: Designing your software to ensure it works before customers have the chance to tell you what you've overlooked so you can avoid the scramble to fix and add these features.
To do this, developers need to strengthen their focus on application design, not on great-looking architecture diagrams or aesthetically pleasing code. Clean diagrams and code are both great benefits that those who value the craft enjoy but are meaningless on top of a poorly designed application. Instead, these things should be byproducts of a pure focus on good design.
Here are a few DevOps practices that can help strengthen the application design process.
Identify specific areas of concern
If you're going to need to change your software tomorrow, you'll want to be able to do that quickly, cleanly and as safely as possible. Remember that every design implementation has a cost to it – such as layers of indirection and additional programming patterns. These things aren't free, and each new element adds to the complexity of the system.
Any time you want to add a new application feature or function, consider when the right time is to do so – or if it even makes sense to add at all. Focus on which specific areas of the product you want to innovate, or which might go through rapid changes as business demands and technologies change. You can't predict all of these upfront, but you can at least make some well-informed and educated guesses.
Be careful with documentation
You need to observe how your customers are using an application, where they spend their time and where they have problems. This way, you'll put more design energy and effort into productive areas.
Integrating DevOps with design means unifying workflows and platforms to promote collaboration and encourage cross-functionality.
For example, I've worked on projects where developers took indirection and abstraction a bit too far. When I was looking in the code to find where the actual work was occurring, I ended up nine layers deep into the stack and almost forgot what I was looking for.
You may use a lot of good design patterns and follow best practices, including sticking to a visual page-worth of code. But you also need to make sure it's easy for other developers and architects to read and understand. In most cases, you can avoid the nine layers of indirection mentioned above, as it's likely those layers don't even need to be modified or changed over time. Including these layers doesn't add value -- it just adds complexity.
Eliminate development silos
DevOps combines software development and IT operations, which shortens development cycles and promotes collaboration and real-time communication across diverse sets of workflows. Design should revolve around a specific plan for constructing a system or implementing a process.
Integrating DevOps with design means unifying workflows and platforms to promote collaboration and encourage cross-functionality. Bringing these disconnected development silos together is a great way to produce better products and deliver them faster.
A brief aside to discuss Ruby on Rails
Let's take a minute to focus on Ruby on Rails. Rails -- a server-side web application framework written in Ruby under the MIT License -- is a model-view-controller framework that provides default structures for a database, web service and web pages. In a situation where separation of concerns is important, Rails offers a great starting point. It can't do everything. You still need design and discipline in your processes and teams but using Ruby on Rails does help.
For example, it's hard to imagine having a project without all the code or without going through code reviews. Rails by itself can't prevent your helpers directory, for example, from becoming a dumping ground for every random method people think of or that they need.
Having worked on many projects where different things like StringHelper classes show up, Ruby is great, because the String class and so many others are feature rich. You don't need the StringHelper class. Because this is the starting point we have, it can be considered like the outline of a picture in a coloring book. It's pretty easy to color outside the lines, use a different color theme, or go outside what you originally intended.
Darren Broemmer is a veteran developer and engineering project manager and has worked at a range of companies, including AWS. Currently, he helps others learn from his experiences as a developer evangelist at DevGraph, a provider of integrated software development tools and support.
