A Blog about Business, Enterprise Architecture and Software Design by the Founders of ZenModeler

The ‘design’ word is one of the strangest beast that lives in the IT world. I hear that word very often as people talk a lot about it. Yet it has a very broad meaning and hence a misunderstood signifier among people, with inaccuracy and positive and negative myths about it… In this article I try to answer to the most common questions about Software Design. You can also replace the word "Design" with the word "Architecture", both are often poorly defined and understood within IT. I personaly prefer using "Design" as a verb and "Architecture" as a deliverable.

A picture I shot while writing this article in the Centre National de la Danse near where I live

What Design refers to?

‘Design’ defines both the activity with the verb ‘to design’ and the result of that activity with the noun ‘a design’.

Can a system have no design?

I had sometimes heard: “this system has no design”. That sentence refers to the lack of a proper design documentation about the system and also sometimes to the lack of attention from the developers to get some insight and structure the system wisely. But a system always has a particular design, sometimes poorly documented and not carefully crafted, but it has one because a source code exists and it runs.

What is a design made of?

A design is about all the decisions made to build the system, both the very large ones that impact the entire system and the small ones with an impact scoped to a small area (a function, a class, a sub-component of the system).

How to best make the design decisions?

  • First question: do I really need to make this decision now?
    • If not, how can I revert this decision later? that question is about flexibility and stuffs that are hard to change after they are done.
    • Or else, what can I do to defer this decision?

Also, always remember to question the validity of the user requirement with a simple « Why? ». One of the most famous experience feedback came from the F16 aircraft design, I advise you to look at that great experience feedback from the father of the F16, Harry Hillaker. In short, US Air Force (the client) ask for a plane capable of a speed over Mach2, but Harry Hillaker was the one who asked « Why? » and the response was « to be able to escape from combat” which was the real requirement. It allows Hillaker and his team to enlarge their perimeter of thinking for the solution and indeed provide a lot of innovations.

If the decision cannot be avoided, check the following three items:

  • Which user’s requirement this decision helps to fulfill?
  • What are the advantages/inconveniences of that decision?
  • Are the responsibilities still clearly separated among components after that decision?

How to properly document a software design?

You’ll have to talk about the “why” of the large decisions that impact the way the system will be structured or will behave. Because if we understand the “Why?”, the “How?” will be easier to grasp. The source code represents the ultimate design documentation of the softwares, but with a huge amount of details. Then we have to abstract that detailed representation, that is to say select only the meaningful information from that ocean of details. But we only get the ‘What?’ (the structure) and sometimes the ‘How?’ (the behavior), which is not very useful if not properly chosen.

What is a good design process?

A good design needs feedback from the user of the system, so the system has to be in front of the user (getting real) as soon as possible, with frequent releases of new versions once the users’ feedback has been received. Hence, a good design process is an iterative and incremental one. There is an acronym for the lack of an iterating process : BUFD for Big Up Front Design. You can also look at that great article from Jeff Atwood about the iterating process in a cat product.

How can a design emerge?

This is a concept coming from the agile world. In short, a design can emerge if we get feedback continuously. Hence TDD and BDD practices help the design to emerge, making all the decisions we need with good insights, because we have a direct and real usage of the system coming from the scenarios. I have had some project experiences where writing the scenarios right before coding – and only with the domain (no persistence, services, web layer, etc.) – saved me hours of refactoring after discovering mistakes I had made in my implementation. Neal Ford has good slides about the Emergent Design concept.

What is the goal of the design activity?

Deliver the best solution to the users given the 4 fundamental constraints of a building project: scope, resources (money is a good shortcut for resources…), time and the most important one, quality.

4 constraints of project

What are the 4 basics designer’s talents?

  • Understand user needs
  • Find an adequate solution
  • Abstract details
  • Separate responsabilities / concerns
    Each one of these « talents » needs a dedicated article because I have a lot to say about those talents.

In the end, what makes a good design?

I would say a design is good when there is a good balance between the different constraints at work, particulary those that are immediate to the end user. Fundamentally, a good user experience is what makes a design compelling. But the others internal quality attributes have their importance, like those defined by the Software Quality ISO norm.