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 (17)


    I do sooooo very agree with you… and work that way!


  2. pr says:

    Most of IT is art (not engineering process), but household art only! There are probably SW areas, where you need to be wildly creative (I consider it high IT art), but these are very rare (maybe development of products).

    The goal of architectural styles (e.g. SOA)/”good practicies”/patterns/frameworks is not to be wildly creative – they reduce number of alternatives significantly. There are still multiple competing designs, but not wildly creative anymore 🙁 We can really live with simple process and achieve “usable design” (greedy algorithm). Perfection is not goal anymore and anywhere! Information asymetry in IT is too high…

    We do not live in 70ties, when IT people were intelectuals. IT pop-culture is winning (see *-driven methodologies). Is that bad? I do not know.

  3. NickMalik says:

    hello pr,

    I find it fascinating that you compare ‘creativity’ with ‘seeking perfection.’  I don’t. I’m seeking ‘good enough,’ but not just good enough functionality, but also good enough feel and design.

    Want to know why I picked a picture of a footrest, instead of a fancy sports car, for this post?

    Because it was mundane.  Ordinary.  Any fourth-grade cub scout can make a footrest.  

    But look at the picture.  A fourth-grader did not make that footrest.  That is design, at work.  

    I promise: if you take to heart the core concept of design, and you take the time to be wildly creative, your mundane ordinary applications can look stellar, and run stellar, and feel stellar.

    Here’s the cool thing: it will cost less.  Why?  Because if a user loves the look and feel and experience of an app, they are far more likely to forgive some minor glitch in the location of a button.  Because they trust you.  But if it looks clunky or ordinary, then you will be back to fix it.

    Design pays for itself… quickly.  Perfection is not necessary.  We don’t need to provide something that is perfect… Just something better than junk.

  4. pr says:


    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

  5. JenG says:

    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’).

  6. NickMalik says:

    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.

    — N

  7. 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:

    1. lack of principles guiding the design (caused by ausence of the EA or by lack of skills of the developer);

    2. 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!

  8. Rick Carmona turned me onto your blog.

    My experience at MS led me to the impression that code/product design isn’t really that high a priority. I tend to over design and I like lots of feedback but I rarely get it.  Everybody is too overwhelmed with a shove-it-out-the-door-while-its-hot attitude and you never have time to come up with even one good design, much less several.

    I believe good design takes time and you won’t get a good one till at least the third attempt.  (for anything complex that is)

    I love your idea – its totally correct but I’ve never seen it possible in the groups I was in.

    I could be jaded because my last team was MSN messenger – a product pulled into pieces by demands from all over the company and micro-managed feature by feature.  Designers would try to come up with innovations and we simply had no time for a rewrite.  Our design was too messy to start with – we couldn’t even test what we had much less rewrite it.

    I wish software designs were as simple as footrests.

  9. Eddie Pasternak says:

    -> "while serving it’s primary function <-  

  10. In my last post , I highlighted the design process, suggesting that designers and architects should consider

  11. pr says:


    I understand your point. Metric "Mean Time Between Maintenance Cycles" makes it very clear.

    I am too wicked already (satan thought out better word for it – it is called AGILE now :)).

    Actually, when I think about it – I do not want to reduce "Mean Time Between Maintenance Cycles" (this metric is influenced by many factors – bad design and by real business changes – it is very difficult to difference between them by customer). But it is something I do not want to fight for in this discussion…

    Have a nice day.

  12. NickMalik says:

    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.

    — N

  13. EA says:

    Thank you, Nick.

    (This is not JUST a politesse: indeed, I do feel grateful for the discussion you opened)

    If I may, however, I’d like to express my dissent from your view.

    What knife does your wife use preparing that wonderful dinner? Mine uses authentic Sabatier. Because she is the wife of a snob? Partially.

    But mostly, because it sits in the hand. It was designed with MY wife’s hand in mind.

    It was made with me, who have to sharpen it once in a long while (extended "Mean Time Between Maintenance Cycles"), in mind.

    Same is true about your simple and elegant footrest.

    So why do we have to teach "functional decomposition"?

    Because 90+ % of the customers shop at the "walmart".

    Knives sold there are very functional: they do cut.

    And if one day they stop (short "Mean Time Between Maintenance Cycles") – you know where to go: we are opened 24/7.

    Same philosophy applies to problem at hand:  outsourced development allows vendors to maintain a targeted profit margin. There is no "margin" for "elegance".

    Chosen few (at MIT and the like), who will eventually supervise the development, might be presented an option to attend an advanced class "S/w development: Milan style".

    The rest, in trenches, has to be taught at least the basics – not every soldier need to be a sniper.

    There is no myth. Very pragmatic approach.

    As to the rest – we are in the agreement.

    Once again – thank you.

  14. NickMalik says:

    Hi EA,

    Your post, referencing Walmart, gave me a good chuckle.

    One thing that I’m not sure fits he analogy, however, is the notion of ‘purchase another one.’  When a person walks in to Walmart to purchase a knife, they have a need to be fulfilled (I want to cut veggies).  When it breaks, and they go back, they have the same need.  Their needs did not change.

    The analogy I presented deals with situations where the needs change, but software is not discarded.  It is more appropriate for a custom-design-analogy than a commodity-purchase analogy.  

    So I respectfully disagree that we should not teach everyone to use creative design principles.  Every project could benefit.  Every developer could benefit.

    That doesn’t mean that every developer will do it.  Some are not creative, and others are not empowered.

    But that is normal human variation.  Some bricks-and-mortar architects crank out ordinary house plans.  Not everyone is Frank Lloyd Wright.  But that doesn’t mean that they don’t follow the same design process.  

    It does mean that they don’t get the same results, and everyone, even the beneficiary of the mere-mortal-architect, benefits when the design process is followed.

    The process of following functional decomposition to its conclusion is a flawed process. It produces products that range in quality from "junk" to "average."  The design process costs the same, and produces products that range in quality from "below average" to "superior."  Which has the lower ‘down-side’ and which has the higher ‘up-side?’  From a risk management perspective, which horse should you bet on?

    My money is on design.

    I, too, appreciate the chance to discuss these ideas respectfully in an open forum.  I don’t believe in shouting matches (as you can see). I have very seldom deleted a posted message (spam notwithstanding).  

    I thank you, honestly, for taking the time to respond to my rambling missives and sharing your experience with me.  Online discussions are a big part of my ‘continuing education.’  

    — N

  15. ЕА says:

    Let’s double the money on the design, Nick.

    The passage, I originally disagreed with, reads:

    `”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”`

    The message I tried to deliver: there is no myth.

    Instead, we are in the environment, when it’s cheaper to replace the broken item ( and, if required, issue a new one), then to do the item right the first time.

    Look at the number of patches, minor releases to a s/w product of a meaningful complexity.

    Vendors cutting time-to-market, sacrificing quality:

    vicious TMQ triangle can be ignored, but it’s there and not scheduled for the departure.

    Proper developer, the one who can take from the architect on, costs ~double to train and ~double to maintain (plus, he tends to be choosy and capricious: he’s an artist in a sense).

    Contemporary business model can’t afford these “doubles”. We can preach, but it’s the business, that is asked to pitch.

    And business, apparently, made its choice (based on some CBA, I assume): it bets on cheap, questionably trained labor.

    We are betting on the horse named “Design”, they bet on a completely different animal.

    And theirs is winning for now.

    Thank you,



    As to the “purchasing another one”. Same LOB is under the technology pressure:

    – those geeky interns who wrote that accounting package are long gone;

    – the business was acquired and now it has to integrate in a SOA’ish manner with something else;

    – the product that the package was built on reached EOL and is no longer supported.

    Yes, I’m looking for yet another knife. And while the times are skinny – my feet drag me to the “walmart”.  

  16. NickMalik says:

    Hi EA,

    You made some good points about the cost of investing in good people… people who choose to use the design process.  

    I agree that we are in an environment where businesses look at these two ideas as "either-or" or "cost benefit".  I don’t believe that they are.  I believe that any individual business can have both.  Some projects can be run using design principles while others are run using ordinary functional decomposition.  

    I wonder, perhaps, if we ASKED every developer to use the design process, if there wouldn’t be more people able to do it?

    I wonder, if we ASKED every developer to use the design process, if quality would increase, even slightly?

    I wonder, if we ASKED every developer to use the design process, if the time to market wouldn’t improve?

    I wonder, if we TRAINED every developer to use the design process, if the mean-time-between-maintenance wouldn’t improve?

    It is good to be frugal.  But buying the cheap knife when the MUCH BETTER knife is on sale for 10% less than the cheap one strikes me as foolish.

    We, the IT community, have to believe in an idea before we can effectively sell it to management.  It is not an idea of "we preach but they pitch."  It is the notion that "a few light the way, and others follow the light."

    Let’s light the way.

    — N

Skip to main content