Last weekend in the “Simple Design and Testing Conference” we had a discussion on “What makes Design Simple” and this is a summary of the discussion we had along with my thoughts.
Well before we go further with in our way of defining simple/complicated design we have to step back and first answer why do we design?
We design to be productive and I don’t do it if it is below the DesignPayoffLine. Now if you read What is software design which I highly recommend you will learn that we design all the time, when customer approves a story he/she makes a design decision (this is interesting, some times we evolve to complicated design when stories are not broken properly), when we write tests (we do test driven development) and programming is also a design activity. So I guess we are always designing with or without knowing it.
Being an agile developer, we don’t focus ourselves on BUFD (Big Up Front Design) but rather we believe in evolutionary design, a design that grows as your system grows and there are benefits of doing that which I will not discuss here (read http://martinfowler.com/articles/designDead.html). One of the key aspects of the evolutionary design is to do the “simplest thing that could possibly work” nothing less, nothing more. There are couple of things that needs to be noted here, “simplest” and “possibly”. Simplest or simplicity is your shortest path to the solution i.e. getting your idea from your head to screen as quickly as possible. And why it is possibly? Because we are not sure whether it will work and that’s why we write test to make sure that our idea works.
But the interesting part is we all start simple (I am totally ignoring the fact that there are teams that start with 200 page design document from day one) and it gets complicated over time because it starts doing more work. But if we could restrict ourselves to keep it simple for tomorrows need tomorrow then I guess we can preserve simplicity and this is where refactoring step fits in. Refactoring is our way to simplify things when it gets complicated. Einstein once said, “As simple as possible, but no simpler.” And I think that makes sense here.
Wait a minute we haven’t defined simple design yet? I don’t think I can define simple in two lines but lets ask the question differently, “How will we know that our application design is simple?”
Software with simple design will enable team members to quickly respond to change. And as your design deteriorates, so does your ability to respond to change. This is really critical for agile projects (again ignoring rest 70% of teams who don’t believe in agile, they really don’t care) because we embrace change and customer satisfaction is important to us. Kent beck calls it “reversibility” property of software. If we can change our decisions quickly it is not a big deal to get them right in the first place and that means less planning upfront (we are wrong most of the times anyways). There are some really good second order benefits to simple design, we get our work done sooner and it is easier to communicate our work with others (I am not sure about you but I still work as part of a team, collective ownership rings any bells?). Above of all it is less stressful to work with simple design.
So how can we keep our design simple? Testability
I absolutely agree with James Bach on ” there are no best practices” but rather appropriate practices and I think the appropriate practice to keep your design simple is continue to write tests.
Testability is a characteristic of software application that provides ability to developers to write tests for their software application. In the world of TDD, we derive our design from tests and having that ability is very important. In fact if it is hard to write test, developers will stop writing tests especially new agile developers. It is very easy to get into “code and fix” mode under agile radar. If you are the only manager reading this article please pay attention to your developers when they say it is hard to test, this could be good indication that application design is deteriorating.
While discussing “What makes design simple” in the conference, Brain Marick raised one interesting point, we should strive for habitability, “The characteristic of source code that enable developers feel like home and place their hands on any item without having to think deeply about where it is”( read http://www.wirfs-brock.com/PDFs/DoesBeautifulCodeImply.pdf). We do spend good portion of our time everyday inside the code we are working on and habitability makes working easy. I guess more appropriate answer to the question “How will we know that our application design is simple?” would be habitability. If it is easy to work with your design, it is simple.
If you are still with me then probably some of these makes sense but if you were looking for top 10 practices for simple design sorry to disappoint. The take way point is “Design for today, not for tomorrow”
Subscribe to this feed