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 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

Day 9: The Business Of Application Development

So far we have focused on the technical elements of application development, and the development processes needed to effectively manage a modern application. But what about the business side? After all, all of us are employed to write applications professionally (or such is the goal, anyway). Open source is one thing, but application development for a business is quite another. This brings us to our ninth principle: modern applications must be easily changeable to meet current business needs.

It might seem that this goes without saying, but there is very real risk here. Application development that is done for the sake of application development is dangerous to a business, because it doesn’t take into account the needs of the business. Applications that are constructed in rigid, inflexible ways are dangerous, too, because business needs change and the application must change with them.

Building applications capable of changing is hard. Most applications are built against a specific set of specifications, and changing the application is difficult. No one expects an application to go from a piece of accounting software to an inventory management system; that would be unreasonable. But applications should be capable of changing to meet the changing needs of a business within their scope. For example, accounting software should be capable of tracking specific payees for reporting purposes; adding this functionality should neither be difficult nor time-consuming.

This is not to say you should future-proof your application so much so that it becomes unwieldy or unusable. For example, asserting that the company might switch from MySQL to Postgres is a silly proposition; if such a switch is demanded, this would typically be out of the normal scope of understanding and the business would need to recognize that significant investments would be required. But as a developer, you have both a responsibility and an obligation to know up front what the next six months to a year of initiatives will be in your business, and to be prepared to embrace and support them. If you don’t know what the next six to twelve months will bring, ask.

Applications that are inflexible or difficult to modify eventually get worked around, and then discarded. Businesses often take the path of least resistance to solving particular problems, and if an application stands in the way, it will be discarded.

When developing your application, consider whether or not the application can be easily modified to meet the changing and expected business needs of the future. You should not engage in mind-reading, but you should have a reasonable understanding of what the business needs are, and what is coming from the future. Embrace the future changes that will be required, and ask yourself if your application can support those changes. Solving for the future will ultimately help you in the long run.

Saturday, January 2nd, 2021 @ 9:00 am | Comments (0) | Categories: Business


Copyright © 2022 by Brandon Savage. All rights reserved.