Responsive Design
Tuesday, 8. September 2009, 19:02:25
I just read Kent Becks article in the third issue of PragPup Magazine called Responsive Design.
His points ring very true with me and I am looking forward to seeing his results become a book at some point.
The fundamental thesis is that software design is not created through a rational process. Rather, the design emerges, guided by the programmer, as a response to the problem at hand.
To think that we are controlling the design of our software is a lie. It is this lie that leads us to believe that we can create big detailed class diagrams before the first line of code is written, and believe that they resemble anything but a fantasy.
There is a very simple way to illustrate why these upfront designs don't work. See, design exists to solve problems. The solution exists because the design does. The design causes the solution to be - brings it into being, but not only it. With a design comes also flaws and imperfections. A design contains decisions, some of which are good, some may be bad and some are compromises. A design causes not only solutions, but also new problems.
These problems may be bug or they may be limitations of sorts, but if we want them solved we will need a design. As this cycle continues, it becomes increasingly difficult to predict and describe problems and design with any level of accuracy. And as fate would have it, we really only have two levels of accuracy: accurate, or not. Even the tiniest assumption can have vast consequences for a design - only with runnable code can we really know what the truth is.
Design grows in response to problems. Responsive Design. But the design is not chaotic. Consider a plant: it is not design - no one can say before the seed is planted, how, exactly, it is going to look. It will grow in what way it finds most meaningful in an effort to solve the problem of survival. But its growth is not chaotic. It has definite lines, purpose and structure. It has parts that are connected in purposeful and meaningful ways.
In short: there is meaning and intent behind the growth of a plant. Likewise, there is meaning and intent behind the growth of a software design. Kents Responsive Design Project is about uncovering and coming to grips with that meaning.
His points ring very true with me and I am looking forward to seeing his results become a book at some point.
The fundamental thesis is that software design is not created through a rational process. Rather, the design emerges, guided by the programmer, as a response to the problem at hand.
Our illusion of control over software design is a dangerous conceit best abandoned.
To think that we are controlling the design of our software is a lie. It is this lie that leads us to believe that we can create big detailed class diagrams before the first line of code is written, and believe that they resemble anything but a fantasy.
There is a very simple way to illustrate why these upfront designs don't work. See, design exists to solve problems. The solution exists because the design does. The design causes the solution to be - brings it into being, but not only it. With a design comes also flaws and imperfections. A design contains decisions, some of which are good, some may be bad and some are compromises. A design causes not only solutions, but also new problems.
These problems may be bug or they may be limitations of sorts, but if we want them solved we will need a design. As this cycle continues, it becomes increasingly difficult to predict and describe problems and design with any level of accuracy. And as fate would have it, we really only have two levels of accuracy: accurate, or not. Even the tiniest assumption can have vast consequences for a design - only with runnable code can we really know what the truth is.
Design is not a rational process.
Design grows in response to problems. Responsive Design. But the design is not chaotic. Consider a plant: it is not design - no one can say before the seed is planted, how, exactly, it is going to look. It will grow in what way it finds most meaningful in an effort to solve the problem of survival. But its growth is not chaotic. It has definite lines, purpose and structure. It has parts that are connected in purposeful and meaningful ways.
In short: there is meaning and intent behind the growth of a plant. Likewise, there is meaning and intent behind the growth of a software design. Kents Responsive Design Project is about uncovering and coming to grips with that meaning.
WIDGETIZE
Anonymous # 16. September 2009, 07:56
Wow,
I really wish Kent Beck would back some of this junk up with quantifiable data, he is going the right way to making a real negative impact on the software industry.
Christian Vest Hansen # 16. September 2009, 08:54
Anonymous # 22. October 2009, 14:52
It would seem to be an even more dangerous conceit to conclude that all design is therefore worthless. Moderation, people :). I've learnt that a good design solution is more akin to a roadmap - don't waste time pretending you'll get every possible scenario/interaction/response all mapped out up front, but give enough direction to ensure you'll arrive at a destination that is at least close to where your customer (whomever that may be, from yourself, to your boss, to a friend, to an actual paying entity) originally intended. It's also kind of necessary if there is more than one person working on the solution, oddly enough.
Anyway, it's a thesis, which by definition is a collated series of assertions that are intended to support a theory, which will either be refuted or supported by facts. Or by whomever chooses to interpret said facts.
Christian Vest Hansen # 23. October 2009, 07:54
It also comes down to what level and scale at which we look at design. Choosing between a switch-case statement and an abstract enum is a design decision. And choosing whether a web site should use sticky sessions or put session state in a grid, is also a design decision but one that exists on a much higher level.
Here, the first example is a problem that you did not know existed before it popped up in your code, and the second example is on you can foresee that you have but it takes a lot of research if you want to decide on the optimal solution.
It is the idea that you can make these decisions up front that I am arguing against, although I may have been unclear. And I interpret responsive design as supportive of this thinking.
So I think that we are generally on the same page, although we may be at different places on that page