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
No Comments »

Here is a quote that recently crossed my path:

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.”
–Brian Kernighan

I believe this is true. Beware if you are being creative when you are writing your software (code). You should be creative in how simple you can make the design for the problem you are trying to solve. Use proto-typing that may create some complex code to get the information you need to reveal the simple design. Don’t leave that code in the system unless it is well incapsulated in a block with a super simple interface to the rest of the system.

Categories: The art of software development
No Comments »

Here is a little advice for the beginner runners out there. You really should buy running shorts, shirts, and socks. Especially as you start getting some distance on your long runs. The technical material really does wick moister away and can prevent chaffing. When you finally go buy some running cloths, buy neutral color shorts. I now only buy black shorts. That way you can avoid some really wacky short and shirt color combinations just before laundry day.

Categories: "Run, Steven, Run!"
No Comments »

I am halfway through the executive EMBA program at San Diego State and recently wrote a term paper on the meaning of work for my Legal and Ethical Responsibility of Business class. Craig P. Dunn gave excellent lectures on the ethical responsibility portion of the class and really made me think about what I am passionate about. It is a topic we often do not slow down to think about. By the time we are in our forties we end up in a job or career that does not align with what we would have picked when we were teens. We can all think of Bob Parr (Mr. Incredible) in The Incredibles movie sitting at his desk as an insurance claims adjustor. Below I examine what I feel passionate about and how it relates to my work.

There are certain books that we read and we are forever changed. One of the first books that I had that experience with was Cosmos by Carl Sagan. In ninth grade, I took that book to my classes and read it instead of paying attention to my teachers. Cosmos actually describes the greatest men and women of science and their contributions. Each of those scientists discovered a simple truth about the nature of the world. The ideas were so simple and beautiful. However, grabbing those ideas from the ether took a great intellectual leap. These leaps are non-intuitive and these great men and women are honored as geniuses for doing it. Kepler’s three laws of planetary motion exemplify this concept. The three laws are so easy to understand, elegant, and obvious. However, discovering the three laws of planetary motion is considered one of the great intellectual leaps in the history of science.

Another event, like reading the book Cosmos, where I felt forever changed is when I took a three day Robert McKee Story Seminar. In that seminar, I found not just new insights about film and story telling for script writers, but deep insights on the human condition. For example, when making a film, the audience is extremely savvy. They will quickly lose interest if the characters in the story make choices that are not creditable. To make characters believable, you must have them do the minimum under each beat in a scene where they have to make a choice. Now each character has a different minimum and for the axe murderer, the minimum may very well be to chop off the head of his victim. I believe this is the same concept of path of least resistance and why building mechanisms to drive progress is the best way to modify behavior. Jim Collins, the author of Good to Great is a proponent of this concept. If we are the protagonist in our own movie that is our life, then we are going to do the minimum based on our environment. Mechanisms change our environment and make our minimum actions align with our preferred behaviors and outcomes. But the one line from Robert McKee I remember above all else is that art is considered a classic when it expresses an eternal truth that does not lose meaning or diminish over time. A classic stays relevant over the years, much like the great laws of science.

Am I passionate about science or am I passionate about film? I realized after some consideration that I am actually passionate about what is common in my approach to both film and science. In fact it is how I approach software engineering and everything else in life. I am passionate about finding the simple structure and truths hidden behind complexity. I am passionate about thinking about the essence of things and having the epiphany and deep insight of a simple truth. I must then be able to express that truth in the physical world in order to be satisfied. With software, I am in bliss when I can do this. My success with software is that I have the ability to reach a point of knowing the deep meaning of a design prior to the actual implementation. When I have been miserable is when we are stagnated and are not moving forward or building software without thinking it through. I am a fan of Joseph Campbell who said “Follow Your Bliss!” which perfectly describes what this seeking a truth and expressing it the world means to me.

Categories: Journal, Notes to myself
No Comments »

I ran five miles yesterday. Four miles at tempo pace in 32:20. Felt pretty good except for the extra weight gained from lagging in July. Note to self, stop eating the kids snacks when working late at night.

Categories: Journal, "Run, Steven, Run!"
No Comments »

The morning of 9/11 my wife and I woke up to a phone call from my mother in-law in distress. She told us to turn on the T.V. and she said she thought my wife’s brother worked in the world trade center. I’ll never forget that morning with my wife and the stress and tightness we had waiting to hear from him. We were fortunate. We reached him later that day and found out his train never made it to work that day (he was running late). We also later learned that he actually worked at world financial across the street from the world trade center–though he often had breakfast in the restaurant in the word trade center. It is one of the moments we all share that divides our lives with a before and after.

Categories: Journal
No Comments »

My story goes back thirty eight years to when I was eighteen months old and had a childhood accident. I fell down the steps of a slide at a playground. Two days after the accident I turned green due to internal injuries and was rushed to the emergency room. A series of surgeries followed. Fortunately the doctors were able to put me back together. Except for having a couple large scars on my abdomen, I felt no affects from the accident growing up. I was even the captain of my high school wrestling team and ran back then regularly to make weight.

That changed when I turned thirty five. At thirty five I was married with two little boys and the co-founder of a software company. I was a bit chubby from the affects of being a family man. It should have been the best time of my life except I started to get intestinal blockages due to the scar tissue that had built up over thirty years. The blockages became frequent and extremely painful. The pain would come in waves about five to eight minutes apart and would last all day. Once the blockage passed I would be back to normal but a little sore. I joked with my wife and would say “I am the only guy that knows what it is like to go through labor”. We started calling it “giving birth”. It stopped being funny when it started happening every two weeks. The pain reached a new level and I even passed out a few times. Controlling my diet and taking medicines had no affect. Even two laparoscopic surgeries did not relieve the problem—I thought I was going to be like this for the rest of my life.

At thirty nine I started to have a mid-life crisis. I negotiated a Mini Cooper and an iPod from my wife—she got a new kitchen. I signed up for a 5k, and started running. After the 5k my brother in-law encouraged me to sign up for the Army Ten Miler in Washington DC. I started training and a funny thing happened. My blockages started to happen less often. When they did happened they were significantly less painful. Running cured me or at least made my problem manageable. Two years later I ran the San Diego Rock ‘n’ Roll Marathon. A friend who is also a runner said she thinks about the pain of giving birth at the end of a marathon to help her get threw the wall. I told her I’m the only guy that can use the same technique. I am a runner now and that has allowed me to enjoy the best years of my life.

Categories: "Run, Steven, Run!"
No Comments »

Okay, this year two couples we know sent e-mails to a distribution list of friends announcing they were getting divorce. It is a shock to get one of those in your InBox–especially when the couples seem to get along so well in their public lives. One of the couples seemed so down to earth and having the perfect life with two great kids. We really do not know what goes on behind closed doors. Who’s going to be next? I realize now that I really do not know.

Categories: Journal
No Comments »

“The sooner our happiness together begins, the longer it will last.” - Miramanee, (The Paradise Syndrome)

“Extreme feminine beauty is always disturbing” - Spock, (The Cloud Minders)

A little suffering is good for the soul. – Kirk, (The Corbomite Maneuver)

After a time, you may find that “having” is not so pleasing a thing, after all, as “wanting.” It is not logical, but it is often true. - Spock, (Amok Time)

Categories: Fun
No Comments »

Welcome to my site. Here you will find insights from my professional experience, blogs I’ve written about software technologies, as well as the occasional blurbs about life in general. I hope you find the information helpful and entertaining.

Categories: Journal
No Comments »