Day 12: Death To The Monolith

How many times have we seen it, where an application does HR, payroll, shipping, billing, makes coffee, sweeps the floors, etc.? Too many times to count for me. The truth is that applications like this, these monoliths, are too large for their own good. Development becomes difficult or impossible, and understanding them is usually relegated to the most experienced developers on the team. This leads us to our twelfth and final principle: modern applications are laser-focused on their specific business case.

The title of this post might lead some to conclude that I am directly endorsing microservices as a solution to problems with application development. That would be an inaccurate reading of my intent. Microservices are great in certain situations, but they don’t apply in each and every one. Let’s explore this a bit.

Microservices are narrowly tailored applications that serve a singular purpose. Think authentication, or sending out an invoice, or adding a person to a directory.

By contrast, the applications I am endorsing are compact monoliths: they do more than one function, and they are as large or small as they need to be to accomplish that specific function. They may or may not talk to other applications via an API (I recommend that they do), and they may or may not allow incoming API requests (again, I recommend that they do). Rather than simply handling authentication an application might authenticate a user, allow adding that user to the company directory, and permit storing information about that user. This is more tasks than a typical microservice.

What I am advocating we avoid is the large monolith, an application so big that it bloats and becomes unwieldy. An application that large is often unmaintainable. It’s often untested. If it is tested the tests are bogged down with extensive functional and acceptance tests that require more time to run than the developers are willing to wait. The experts on the application are usually the people who have been there the longest, and I don’t have enough fingers to count how many times that has been a single person. What happens if that person is sick, or wins the lottery and never comes back into the office?

Monoliths present deployment challenges, too. They’re difficult to build automatically (see lack of testing, above). And they’re difficult to deploy, meaning the deployment cycle is often very slow. Developers are often scared to deploy a monolith so they don’t; this only delays the inevitable, and the longer you go between deploys, the greater chance of bit rot. Bit rot happens because things left unattended always unravel, memories become spotty, and developers lose sight of what they learned in the past and must relearn it. All of this leads to poor business outcomes.

If your platform is customer facing and you have a huge monolith, this presents an incredible challenge, too. First, you’re unlikely to deliver the latest in features and benefits to your customers, and they may go elsewhere. Second, when you do deploy you’re more likely to ship bugs along with the new features, and these bugs may not be corrected for many days or weeks if your deployment process is slow. You may find yourself faced with challenging decisions to roll back or fix in place, which is a decision no CTO wants to make.

Smaller applications, even if they are monolithic in nature, typically don’t suffer from these problems. The reason why is that they are easier to test, simpler to deploy, faster to fix, smaller to understand and quicker to be fixed in place if problems are discovered. APIs allow the applications to communicate across clearly defined boundaries, ensuring that you get the benefits of microservices without the hassle of deploying dozens of services just to achieve one task.

So embrace the compact monolith. Shun the large monolith. Your applications will be better for it, and so will your application development process.

Thursday, January 7th, 2021 @ 9:48 am | Comments (0) | Categories: Business, Development

Day 11: Your Development Environment Matters

We’ve all been there: staring down a new project with 14 steps to set up the development environment, and step 2 breaks. We spend hours debugging, only to be told by a senior engineer, “oh, yeah, the docs are out of date, here’s new instructions”. You try the new instructions, which are also broken, and are finally told “oh, there’s a trick, see…” This frustration brings us to our eleventh principle: modern applications must be easy to develop.

Modern applications should have simple, straightforward development environments in order to facilitate easy developer access and onboarding. A complex setup for a development environment, or one that takes days to master, leads to frustration and disgust before a developer has even written a single line of code.

By having an easy-to-use development environment, companies can ensure their developers are always working on the most modern instance of the code base, and make certain that developers are focused on developing, not maintaining an ancient and fragile development architecture.

Containerization, Vagrant and others have made this process easy and simple. Taking the time to invest in these tools might seem like a waste, but will speed developer productivity, make testing simpler, and reduce the number of bugs making it into production. It requires a hard look at the actual architecture of the application and, often, a simplification of that architecture.

Development environments aren’t sexy topics, but they are critically important for developing and deploying code that runs, and runs well. Invest in them. Make them simple. Make them easy to use.

Tuesday, January 5th, 2021 @ 9:31 am | Comments (0) | Categories: Development

Day 10: Balancing Business And Development Priorities

If you asked a development team about an application, specifically asking how that application should be developed, they would probably tell you that the application should be developed to be as easily maintainable as possible. If you asked the business analysts the same question, they’d probably say that an application must serve the business needs exclusively, and that features should be packed on as fast as possible in order to meet those business needs. Who is right?

Turns out they’re both wrong. This leads us to our tenth principle: modern applications must be oriented to the developer, but focused on the business.

You’re probably thinking, “well that makes no sense.” Let’s break this down a bit.

What does it mean to be oriented to the developer? It means giving developers time to make the project easy to maintain and build. It means ensuring that developers have the ability to make changes and improvements independently of the feature cadence, so that the project doesn’t die from technical debt or abuse. It means giving developers the time they need to experiment with new technologies that might make the project run better or more efficiently.

Focusing on the business means giving the business what it needs to do business, and be effective. It means prioritizing features to a degree, and ensuring that necessary or critical features are not backlogged by bureaucracy or red tape. It means ensuring that the business needs are met, as a high or the highest priority.

How do you balance these things?

To orient to developers while focusing on the business, you must leave space for both needs and allow both needs to be accomplished. For example, most businesses love to maximize their story points in a given week; they want to make sure feature development moves ahead at full speed. But a forward-thinking business will leave 25% to 50% of a developer’s schedule unfilled. This number might seem really high at first but consider: bugs are not considered stories but must be fixed. And for any enhancements or improvements to be made outside the system of story points, user stories and feature requests, developers need time.

For their part, businesses would do well to ensure developers understand the business needs –  not just from a “here’s what the business needs” perspective but from a strategic, big picture perspective. Developers like to be involved, and they can assist much more effectively if they have the big picture.

This is really a long way of saying that business and development need to balance each other’s needs, prioritizing one thing some of the time, and another thing other times. This careful balancing act never ends, and both teams should meet regularly to ensure the balance is correct and that the business (and application) are moving forward at the right pace. This balance will achieve great results for your team, but only if you let it.

Monday, January 4th, 2021 @ 8:45 am | Comments (0) | Categories: Business, Development


Copyright © 2022 by Brandon Savage. All rights reserved.