The bizarre assumption of functional decomposition
I ran into a friend today and, as friends often do, we let our conversation wander over the different "broken things" in IT in general (and a few in Microsoft in specific). One thing that I'd like to share from that conversation: a truly bizarre assumption that we teach, over and over, to new programmers... the assumption that simply following a "functional decomposition" process, a well-trained programmer will naturally end up with a good design.
Now, I'm no great expert on product design or graphic design or industrial design... but one thing I can say for certain: creating a good design is not the natural outcome of a simple process. Only an excellent design process can produce excellent design.
Let me provide an example of good design from the world of products. This picture is a picture of a footrest. You read that right: a place to rest your feet. Mundane, right?
You tell me. Does this product LOOK mundane to you? How about the fact that it promotes movement and blood flow while serving it's primary function? (special call out to the design firm, humanscale, for creating this beautiful product.)
Design is not just a process of decomposing a problem into its constituent parts. Nor is it a process of creating objects that contain functionality and data... yadda-yadda-yadda. There are dozens of techniques. Don't read my blog post as a slam on any one of them. I'm slamming anyone who thinks that they should reach a conceptual architecture, derive one solution, and go... without considering alternatives.
Design is a process where you consider the problem and then propose multiple, competing, wildly creative solutions. You then narrow down your brainstorm and weed out the bits that won't work... and then you propose multiple, competing, wildly creative refinements... and the cycle continues. This happens a couple of times, until you have refined your solution by being creative, then logical, then creative, then... you get the picture.
When was the last time you were in a design review and the team being reviewed came in with multiple solutions, asking for help to narrow it down? Really?
In no other field is the word 'design' so misused as it is in software development.
I have not met many folks that use a process whereby they design multiple, competing, wildly creative solutions in software and then evaluate them, select one or two, and go after the problem again at a finer level of abstraction.
Not many folks at all.
Why is that? We are living with the myth: that you can follow a simple process, produce a simple and "pretty good" solution architecture that represents a "good design". No alternatives. Very little creativity.
How's that working for ya?
Comments
Anonymous
October 27, 2008
PingBack from http://mstechnews.info/2008/10/the-bizarre-assumption-of-functional-decomposition/Anonymous
October 28, 2008
SPLENDID! I do sooooo very agree with you... and work that way! -JackAnonymous
October 28, 2008
The comment has been removedAnonymous
October 29, 2008
The comment has been removedAnonymous
October 29, 2008
Nick, Creative approach is way-of-doing only. More funny, more interesting, but way-of-doing only... It is standard decision - process vs. creativity. I have not understood your goal correctly (I though it is perfectness). What is the real goal of your approach? Why I should invest time to it?
- Decrease costs by better relationship with customer? (Actually I do not accept this argument. I do not want to have delivery process based on "customer forgiving".)
- To have more fun in work?
- To look stellar? My goal is to deliver value to customer - something what he needs to make his business. Reasonable service for reasobable price (and to be fair, because business is not everything...) - not to make him "happy". We can really follow a simple process and produce a simple and "pretty good" solution architecture that represents a "quite good design". I can outsource wildly creative decisions to framework/process/best practicies/architecure style developers. It is not myth. There are not too many IT snobs who are interested in IT creativity :) Btw. Please try too be more loosely coupled :) Not all consumers of your blog are as good at english as you. Thanks
Anonymous
October 30, 2008
Couldn't agree with this post more. Applies to all aspects of software design and not just the presentation- and unfortunately those of us who do this stuff for large organisations are so conscious of time up front that we forget that we could save it later (plus cost) if only we spend a little longer getting it right (or 'good enough').Anonymous
October 30, 2008
Hi pr, You are asking valuable questions. I'm glad to be discussing this point with you, because I think other folks feel like you do. Here is the core question that I'm hearing you ask: What is the business value of elegance? Before I answer, I want you to think about the things that you use in your life. Do you drive a car? If so, what car did you choose? Did you have a choice? Did you select the least expensive choice? Does your car have cupholders? How about a nice CD player? Automatic mirrors? Did those things affect your decision to buy it? (Remember, none of them are necessary for the operation of the car). When you go to a store to purchase a new shirt, what do you look for? Does the feel of the material matter? What about the style? What does it say about you? What is the most popular feature on the new Google telephone... is it the weight? The color? Nope. The phone purrs when you pet it. I'm not kidding. It purrs, like a cat, or if you are a fan of the old TV show Star Trek, it purrs like a tribble. The car you drive, the shirt you wear, the phone you carry... they all reflect you. You make a choice to select those items, and you feel good about doing it, because the result reflects on you. If your business customer is writing a check to your IT group for $80,000 USD for a software solution (or $800,000, or $8,000,000), don't you think that they are aware of that money? It isn't a joke. They are aware of the fact that they are personally spending money. The result has to reflect the business, but it also has to reflect them. I've had business customers who loved my product because they could choose a background photo that sat right behind the data entry fields. I've also had a business customer who cancelled a project, after spending $3,000,000 on it, because the user interface didn't look pretty enough. (They were right). The point is that we do more than deliver a technical solution. We are solving a business problem, and if the solution is used, it is useful. If it is not used, it is not useful. One of the key indicators of whether a solution is used is the emotional state of the user. Creating a system that the user doesn't enjoy using, no matter how functional, is creating a system that is not useful, and that is wasting money. You don't have to seek perfection, but if you take a little bit of time and consider alternatives, and brainstorm different ways, you have something to work with. You will like the results more, and your client will use the results more, and that means that they will be happier with it, and it will last longer between maintenance cycles... which saves buckets of money. The business value of elegance is usefulness, and it is measured in the time that it takes between the day you deliver the software and the day the next project starts to change the software. The longer you stretch out the time, the more your business saves. Good design extends the "Mean Time Between Maintenance Cycles" dramatically, thus saving money. Why does it do that? Because your customer will become emotionally attached to good design. And they won't want to change it if they like it. That's the business value of elegance. --- NAnonymous
October 31, 2008
Hi guys, I'll just try to join the discussion, really nice footrest btw! Into the creativity issue and the prototyping/refinement, I guess the biggest hurdle to see development processes running like that is the lack of principles to guide the development. The reason most of the people doesn't see the business value of your proposal is it wouldn't deliver quantifiable results in their organizations for:
- lack of principles guiding the design (caused by ausence of the EA or by lack of skills of the developer);
- It's still very hard to qauntify the benefits of such a investment, but you're consuming the same resources (people/time) from where you measure the effectiveness of your overall investment; Your Elegance relation to the Mean Time Between Maintenance Cycles is very good, but I would point first the Usability factor as a productivity enhancer. Well I got a bit lost, hope I made some ideas through this posts. Thanks for the reading!
Anonymous
November 02, 2008
The comment has been removedAnonymous
November 02, 2008
-> "while serving it's primary function <-Anonymous
November 02, 2008
In my last post , I highlighted the design process, suggesting that designers and architects should considerAnonymous
November 03, 2008
The comment has been removedAnonymous
November 03, 2008
Hi pr, I do think that Agilists are more amenable to good design. I posted a new post on the mean time between maintenance cycles. Thanks for the discussion. -- NAnonymous
November 11, 2008
The comment has been removedAnonymous
November 11, 2008
The comment has been removedAnonymous
November 12, 2008
The comment has been removedAnonymous
November 13, 2008
The comment has been removed