Negative Space And Forming Business Strategy

September 6, 2010 7:42 pm

Negative space in art is the area around the subject that you are drawing. In an art class, you may spend a whole lesson drawing the negative space of an object. In forming a business strategy, the negative spaces are those things you say “no” to. You should use the negative space to help you draw your strategy. The things you say no to will help you better understand what you are choosing to be best in the world at.

Griffith’s Law of Software Economy

May 11, 2010 4:18 pm

Occam’s razor is a principle that “entities must not be multiplied beyond necessity.” In software development, I believe strongly that smaller code is better. I humbly call this my “law of software economy.” Another way to state Occam’s razor is “plurality should not be posited without necessity.”

Now you can’t cheat and make your code small by making it intelligible. It is the smallest code that can be easily understood by SOMEONE ELSE! The reason the law of software economy works is because smaller code naturally minimizes the knowledge that objects have of each other (decoupling) and has very little redundancy (cohesion). More knowledge and redundancy takes more lines of code! Reducing lines of code encourages minimizing layers and layers of interfaces that add no value and make software hard to understand. Have the right and minimal set of interfaces. Reducing lines of code also encourages conventions over configuration. If you buy that every line of code is a chance for a bug, then it also improves quality. Writing smaller code is not faster to develop than writing larger code in the short run. However, in the long run, it will inevitably always win the race.

The smaller the software and elegant the architecture the better chance you can hold the design in your head. The the ultimate position of power is to have a god like knowledge of the system. If you have excessive and overly engineered code, trying to keep it between your ears is like playing musical chairs. Good luck with that.

To the bone, knowing what you are meant to do

12:27 am

One of my favorite quotes–can’t find it credited online but I saw Ed Harris say it in a TV interview, so it’s a bit mangled from memory–is that when someone asked him about his choice to become an actor he said, “I didn’t have a choice, I had no choice, I had to act.” I always think about that statement; I think it separates those that give up and those that have no choice but to keep going for it (a.k.a. to the bone, knowing what you are meant to do).

When the going gets tough, innovate!

April 23, 2010 3:09 am

A crisis can drive innovation. Being able to hold the software in your head at a high level because it is well architected can give you many ways out of a bad situation. Often you surprise yourself how easy a leap forward can be once you have no choice but to find a way! Many of these great ideas live in the back of your head and a crisis will force one to the surface. Solving a problem, in a beautiful way, when your back is against the wall is a rush, and thrill. Especially when you may have been the first to solve it that way.

CEOs are Story Tellers

April 19, 2010 2:44 pm

CEOs are story tellers; you’ve got to create a story people want to work for, a story people want to buy, a story people want to invest in. A fantastic story may be your last when it doesn’t come true. An unexciting story may never get off the ground. How far do you stick your neck out to create goosebumps–that’s the rub.

Average Software Developers Create Suffering in the World

July 24, 2009 4:16 pm

Elite runners get to finish Marathons in less than two and half hours. The average non-professional runner is going to be grinding it out for over four hours. Who suffers more? In some ways the average runner is going through a unique hell that an elite runner never experiences.

The same is true for software. Great software developers end up with simple solutions to complex problems. The novice and average software developer creates really complex code for complex problems. To hold the simple design in your head and code is not as taxing as holding a overly creative complex solution and getting it to work perfectly. I feel sorry for the novice and average software developer who suffer because they code before the simple solution is understood. But it doesn’t end there, elites suffer when they have to go in and fix the untamed solution later because no one remembers all the secrets in the implementation.

One elite I know who had to fix some old code said after the experience:

“We should find the person who wrote that and show him a computer and tell him he is not allowed to ever touch one of these ever again.”

#1 Rule of the House

6:48 am

Ask our two sons what the #1 one rule of the house is and they know it by heart:

“When Mommy’s happy, we’re all happy.”

The Five Mantras of Software Development

April 10, 2009 4:19 pm

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.

An argument against being creative when coding

November 20, 2008 7:46 pm

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.

Some advice for the beginner runner…

March 20, 2008 5:12 am

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.