A New Guiding Principle for Application Development

In the world of application architecture, there are lots of guiding principles that could be followed.

One such principle is Service-Oriented Architecture. In a Service-Oriented Architecture paradigm, application functionality is delivered in a modular fashion via discrete, self-contained services. This is a great architecture that allows your back-end application components to be made reusable. While this type of architecture can provide significant efficiency gains in large architectures, it can be inefficient if applied to small applications or one-off applications whose data isn’t helpful to the larger enterprise.

Another such principle is TDD: Test-Driven Development. Test-Driven Development is a principle wherein the developer attempts to maximize the testability of their code. Unit tests are often written before the code is written to ensure that the tests are sufficiently independent from the code. The goal with Test-Driven Development is to improve the developer’s ability to quickly and easily maintain and update the code. As someone who loves to be able to just make a change, re-run the tests, and call it good, I can vouch for the fact that the results of this principle are overwhelmingly positive. Another testing-related principle is Acceptance Test-Driven Development. In this case, the tests are not unit tests but functional tests that are agreed upon by the team before development begins.

Well, today I’d like to propose that a new guiding principle be added to the agile team’s toolbox. I’m calling it Product Focused Development, because the product is the focus. Its guiding principle is a new manifesto. I call it… wait for it… The Product Manifesto. Original, huh?

The goal here is not superior testability nor superior modularity but, rather, superior functionality. Apple would be an example of a company that embraces this principle in its product lines. They may not have the most advanced back end or the most advanced data-sharing architecture, but they do make some of the best, easiest-to-use, and most efficient devices known to man.

This new manifesto would go something like this:

Our goal is to produce a superior product exceeding the expectations of the user not through an overwhelming number of features but by the overwhelming quality of our output.

To this end, we prefer:

Simplicity over Complexity
Design over Features
Quality over Technology
Intuitiveness over Innovation

The goal here is to make our product as excellent (from its user’s perspective) as it can possibly be. Our goal is not to use the latest technologies nor the coolest approaches nor the most intricate and impressive back-end architectures. Our only goal is for our product to be as good as it can possibly be for the end user.

To be clear, this doesn’t mean that we disregard testability or modularity. In fact, those building blocks will help us to continue to produce a better product. What it does do, however, is put the emphasis on the one thing that matters most in the end: the deliverable. Pay attention to the fact that we’re favoring design over features, and quality over technology. If you want to use some new cutting-edge technology, it must improve the product, and do it more easily and effectively than other technologies can.

Notice that this means that architectural decisions now fall under the microscope of the team more than they might have in the past. You want to implement the new product using a SPA approach? Let’s make sure that produces the best product for our users. Traditional multi-page website? Are we sure that is the best approach, or is it just the norm?

Of course, there are some requirements that you can’t simply say “no” to. Does your organization require you to use an ESB or TDD? This doesn’t mean that you can ignore those directives. If those requirements are outside of the control of the team then you’ll just have to implement those technologies in whatever way impacts the user in the most positive (or the least negative) way.

As an Enterprise Architect, this principle does make me a little uneasy, but it does produce a higher-quality product, at least in the short term. As with all things, pragmatism should reign. Do what makes the most sense and meets all requirements, both for the product and for the underlying enterprise architecture. Just do it in whatever way is most beneficial to the product and, by extension, the end user.

In respect to this principle, your architectural rule of thumb should be to strive to minimize architectural complexity in order to maximize product usability.