Those that have worked with me know that I am passionate about getting to the simple truth that lies below the surface of what may at first appear very complex. I believe discovering the fundamental use-case of a product and describing it in its simplest form empowers a development team to create killer applications for users and maximum economic value for a business. Our job as software architects is to reveal the simplest design that delivers the use-case in a beautiful way so that we minimize the complexity of the system. Complexity in a design is a sign that we did not get to the simple truth and prematurely wrote software. I purposely use the terminology “reveal a design” rather than “design the design” because I believe a design already exists and our job as software artists is to reveal it.

“In every block of marble I see a statue as plain as though it stood before me, shaped and perfect in attitude and action. I have only to hew away the rough walls that imprison the lovely apparition to reveal it to the other eyes as mine see it.” - Michelangelo

There are a lot of software development processes that help teams build software. This article is not about a software development processes (e.g. Scrum, XP, and RUP). This article is about the art of software development from a design perspective and put in the simplest language possible. The goal is to show how it only takes a few easy to understand mantras to develop designs that can scale and grow into large systems. Software development processes help teams work together to create software, but each developer will find using these mantras useful no matter the type of software development process they are using.

Often you do not have the entire problem understood when you have to design and deliver a software product. The mantra “build one to throw away” really does not work when creating large systems. Too many times the code you expect to throw away ends up being the product. Then you have a software base that is flawed and ultimately collapses as the demands of the system exceed the ability of the team to evolve the software. The worst thing that can happen, the software developers become creative and add secrets deep inside the code. Here I am talking about the kind of creativity that makes the complexity of the system grow exponentially and ultimately causes you to hit a brick wall. The result, in time, even those that wrote the software do not remember all decisions in the software they produced. Are your developers running the software to see what it does? Are they reverser engineering their own software?

The brick wall happens because a poorly designed system’s complexity grows exponentially with every feature request. You cannot evolve software organically into large systems. Following good object oriented design practices from the beginning allows a system to scale linearly. Scaling a system linearly with each feature request is important because it drives the return on investment of the development team. Achieving a high return on investment from the development team allows a company to create economic value.

Design patterns, object oriented analysis and design (OOAD) terminology, and other concepts are drilled into the heads of all software developers. Unfortunately, from my observations, only about five percent of developers truly become masters of object oriented design.

Note: The reason there are so few is that true software masters have spent at least 10,000 hours writing software with intense passion in a short period of time (few years). For them writing software becomes more than a career choice. Malcom Gladwell’s Outliers gives a nice qualitative argument that supports this concept.

Other software professionals often have good working knowledge of principles but struggle in creating simple designs for large systems. In fact, the master software developer creates very small code that does a lot while those that struggle create much more software with often very creative solutions to accomplish the same task. The extra creativity is the root cause of problems with scalability and understandability of a system.

If every developer asks the following mantras for every object they create, then they could greatly simplify their designs, and increase the scalability of the software that they are building. The mantras are great questions to ask during code reviews. The mantras allow a place for complex code to exist where the simple solution has not yet been found. It keeps complexity or poorly designed code from co-mingling with the rest of the system. The mantras allow for a higher-level understanding of the design to be revealed over time. The challenge for the developer is determining how deeply you need to adhere to the mantra for any given circumstance. The idea is that satisfying the mantra is easier to understand than textbook object oriented design lingo. Those practices taught in books, classes, and seminars are simply techniques to satisfy the mantras. However, blindly following the formal solution can often produce overly complex code that sometimes still can miss the most important goal, building a system that is easy to understand and will scale. An easy to understand system is easy to use and easy to test.

OOAD MANTRA #1 - Why does that know about that?

Now, I must admit that these mantras are really simple sentences for well known OOAD principles. The benefit of having a loosely coupled system is well known. The first mantra simplifies how to look for coupled objects in your code. When two objects interact, are you hiding as much knowledge as possible between two objects? Often I see information about objects flowing deep down into a series of methods of a package that has no business knowing about that object. In a code review, simply look at the system with one question in mind, “why does that know about that?” Using interfaces, abstract classes, and inheritance may feel like your decoupling but it is meaningless if you do not adhere to OOAD Mantra #1. Your time is well spent to actually rework your software as soon as you identify objects that should not know about each other’s business.

OOAD MANTRA #2 - Why do we have two of those?

Another well understood OOAD principle is that of cohesion. Cohesion is the idea that a class should do related tasks. I like to think of a class as having a well defined purpose. If you have classes with well defined purposes, then you shouldn’t see another class in the system doing the same thing. When a class is doing too many things, you are adding hard to understand complexity to the system. You should not have two classes do the same thing and you should not have a single class do too much. You shouldn’t have two methods of a class that do the same thing as well. Quality is greatly improved when you can keep classes very small and focused on specific tasks. If you see similar code in many places then a developer went to town with “copy and paste.” Stop and rework or that code will be in the system forever. The biggest cause of “copy and paste” is because the developer didn’t adhere to OOAD MANTRA #1. Test complexity can grow exponentially if you do not adhere to OOAD Mantra #2.

OOAD MANTRA #3 - Why is that public interface so complicated?

The other part of cohesion is creating classes with related tasks. I like to think of a public interface as the definition of a box. The outside view of the box must be simple. I do not care how bad the code is in a box, if the box has a simple public interface that can easily be unit tested. You can, at a later time, improve what is inside of the box with very little impact on the system. However, if the spaghetti inside the box leaks outside into the public interface, then that box is patient zero of an infection that can contaminate the rest of the system. Like Pandora’s Box, no harm comes if you can keep the lid closed.

OOAD MANTRA #4 – Do we really need that to be configurable?

The proliferation of configuration files is a sign that developers are not willing to close doors. When are ten lines of code better than 500 lines of XML configuration? Always! Convention is a great option not used enough to reduce the need for overly verbose configuration files. Naming conventions allow for great simplification to the external configuration of the system. If you consider configuration files as part of the public interface of a system, then OOAD MATRA #3 would question exposing complex configurations that never needs configuring. Keep the public configuration simple. Lots of configuration can be eliminated if developers just made more decisions rather than leaving every possible option open for someone else to decide. The brilliance of Apple products is how the applications hit the sweet spot, the interfaces are beautifully simple, and there is just enough configuration and no more. Simply, developers should make choices and be minimalist.

OOAD MANTRA #5 – Where do we need extreme decoupling?

In a system, there are a handful of places where it pays to do extreme decoupling. This is where the business application would receive leveraging if those elements could be expanded easily. For a statistics package it is statistical methods, for a plotting package it would be charts. The best extreme decoupling areas enable outside resources to extend the capabilities of a system with limited knowledge of the whole system. Just consider how much third-party plug-ins increase a Web browser’s value. Software developers get excited and passionate about decoupling behind the scene services that never change or change once in a blue moon. We should decouple framework services, but that passion needs to be brought to the application level and for its specific decoupling needs.

The above mantras have served me well and I hope you find them valuable. It is a well-known fact that people on average can hold seven things in their heads while more than that can be very difficult. That is why functions in software should be limited to seven arguments. Thus, I think I have room for two more mantras. I’m open to suggestions and will consider extending the list if they are fundamentally important.

Categories: The art of software development