Win a copy of Spring in Action (5th edition) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Vitruvius:commodity, firmness, and delight  RSS feed

 
Ranch Hand
Posts: 348
8
BSD Debian Open BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Corey,
The ancient Roman architect Vitruvius considered the question:

what makes a good building?


In his treatise De Architectura Libri Dece (Ten Books on Architecture), written in 29 B.C., he proposed three principles that many think provide a good starting point for
evaluating software designs.

A well-designed building, said Vitruvius, should have the qualities of commodity, firmness, and delight.


A product that balances commodity, firmness, and delight does not necessarily possess an equal amount of each. Most people think a good cup of coffee should contain more
coffee than cream or sugar.

  • When you buy a software package, you want it to do exactly what the box says it will do. This is the characteristic of commodity—the program is effective in the sense of being well fit for its purpose.
  • You also want the program to be well built: you want it be as fast and small as possible, and to continue working in a wide range of situations. This is the characteristic of firmness.
  • Finally, you want your software to be attractive and pleasant to use. In a sense, you “live inside” your software, and it’s important that the interface be both functional and aesthetic. This is the quality of delight.


  • Each of these qualities is important. Good-looking software that doesn’t run well or is hard to use is no better than software that is fast and efficient (that is, software that uses
    as few resources as possible) but doesn’t do what you want or does it in an ugly or unappealing way.

    Software designers,  tend to see the design process through their own particular lenses and to concentrate on one specific aspect or method of designing programs.
  • Some see software development as a scientific endeavor.
  • Others see it as an engineering exercise.
  • Still others think of designing computer programs as artistic expression, like painting or music


  • DESIGN AS ARCHITECTURE
    If “firmness” is the special purview of the engineer-designer, then “delight” has a similar place in the world of the artist-designer. Yet, concentrating on firmness and delight is not
    enough; the designer must also be concerned with commodity, balancing form and function. In this regard, many software designers see a close parallel between their role
    and that of the architect. This analogy was the central theme of Mitch Kapor’s “A Software Design Manifesto,” and the similarities between software design and
    architecture have greatly influenced the “patterns” movement
    Like the artist, the architect wants to build structures that are visually pleasing; visual design is central to every architect’s training. But, like the engineer, the architect wants to
    build structures that stand the test of time. The science of materials and construction techniques is an important part of an architect’s training. In the end, the architect designs
    neither for beauty nor for durability, but for the client. The architect’s goal is to build a structure that meets the client’s needs.

    Based on your experience what you think about those considerations and what is  the best way to meet commodity, firmness, and delight qualities in a well balanced manner?

    TIA
    Harry
     
    Sheriff
    Posts: 12747
    210
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    For the curious, Mitch Kapor's "A Software Design Manifesto" can be found here: https://hci.stanford.edu/publications/bds/1-kapor.html
     
    Harry Kar
    Ranch Hand
    Posts: 348
    8
    BSD Debian Open BSD
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Mitch Kapor is a great figure in our field I discover only in later years he was the father of the renown back then Lotus123 spreadsheet and above all one of the first persons who thought about the role of software designer (as an architect) as a standalone professional figure apart his novel (back then) ideas about software design. Despite Capor's labour some nowadays profs seems ignore all that or almost have some problem to teach software design isn't  
     
    author & creator of coderetreat
    Posts: 14
    6
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Harry Kar wrote:Hi Corey,
    The ancient Roman architect Vitruvius considered the question:

    what makes a good building?


    In his treatise De Architectura Libri Dece (Ten Books on Architecture), written in 29 B.C., he proposed three principles that many think provide a good starting point for
    evaluating software designs.

    A well-designed building, said Vitruvius, should have the qualities of commodity, firmness, and delight.


    Based on your experience what you think about those considerations and what is  the best way to meet commodity, firmness, and delight qualities in a well balanced manner?

    TIA
    Harry



    Thanks for this great question, Harry.

    My answer for "what is the best way to X" is almost always "understand the people who will be using your system." Or, in other words, "communication and empathy."

    In your message, you talk about the different roles and different goals as though they are happening in a vacuum. If they are, then I think there will always be problems in balancing them. Some people will want one thing, others will want to emphasize another. But, if you bring everyone together and truly understand WHY you are building what you are building, then it is more likely that you can achieve the right balance of these three qualities.

    For example, it may turn out that you may not need to emphasize delight at the beginning. Or perhaps, at a certain stage, you maybe not need it to be you want it be as fast and small as possible.
    As a concrete situation, I'm currently working on fixing a rather tough bug. There is the "correct" way to fix it, but we are going to go with the way that is quickest to implement in order to get it into production. Then, we may come back and adjust it to be faster / smaller. We may not, though.

    Whenever there is a concept of "as possible," we run into problems. Instead, I would say that we want to balance these three qualities to "just as much as needed," which means we need to start with understanding what is needed.

    Hope this makes sense.
     
    Harry Kar
    Ranch Hand
    Posts: 348
    8
    BSD Debian Open BSD
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Corey i guess i got what you meant and really appreciate

    I casually found an interesting article   Designers Will Code what you think about ?

    TIA,
    Harry
     
    Sheriff
    Posts: 23867
    50
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    If we're going to accept the ideas of Vitruvius on designing and creating a building as a metaphor for designing and creating a software system, then by all means let's go with that metaphor.

    Let's suppose you are a building contractor who is responsible for creating a house for a family to live in. Then "commodity, firmness, and delight" -- absolutely. But you are going to hire some people to do the actual construction work, rather than doing it yourself. So, should you know how to use a table saw and a nail gun? Should you know how to install electrical wiring? I would say yes; even if you never pick up a hammer you should still be able to understand what the actual people with hammers are doing and you should be able to talk intelligently about why putting a door in a certain location is a problematic feature of the house's design.

    But now let's suppose you are an architect who is responsible for creating a 70-story office building. There's a lot of things which have to happen for the building to be constructed, so you're going to have a team of engineers to make those things happen. They in turn are going to hire crane operators and electricians and heating system designers and accountants and so on and so on... so should the architect be able to, say, make sure that workers are paid correctly and have the correct taxes deducted? Or know how to install a high-rise crane safely?

    I'd say no to that. But maybe "Designers Will Code" in the software field should correspond to the idea that architects should be qualified engineers, so that they aren't guilty of designing 70-story buildings which the engineers can't build? It doesn't seem to work that way in the real world, I'm pretty sure that architects don't have to get an engineering qualification before they can start architecting things.

    But the article you linked to seems to be talking about small-scale systems, the kind which only have a few people working on them. Those systems correspond to the contractor building a home for a family, so the analogy holds true in that case.

    Now let's look at a large-scale system, let's say the system which manages the payroll for the government of Canada. Have a look at Phoenix pay system for some background on that ongoing disaster. In that case the problem wasn't that the designers couldn't code, it was that the designers didn't know how to pay employees. The requirements were more complicated than expected and the designers didn't spend enough time identifying all of the different ways you could be paid if you worked for the Canadian government. Like Corey said, "understand the people who will be using your system". That didn't happen in the Phoenix project.

    So yes, for small-scale systems (which is most of them, really) I'd agree that the designer ought to be able to get their hands dirty and do some coding. But for large-scale systems I'd suggest it's more complicated than that.
     
    Harry Kar
    Ranch Hand
    Posts: 348
    8
    BSD Debian Open BSD
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Paul take a look at  What Is Software Design and Why Is it Needed?

    I don't thing Quora(like Fb or Google) be a small scale project; regard your link i take a look tomorrow or when i have free time

    The problem i notice is that almost all people in all places(here too) talk about coding dissecting code ecc and only very few(if any) talk about design; and the problem IMHO starts just from Uni's education  
     
    Greenhorn
    Posts: 3
    Linux Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You can get the "Ten Books on Architecture" free at https://www.gutenberg.org/ebooks/20239
     
    permaculture is largely about replacing oil with people. And one tiny ad:
    Download Free Java APIs to Work with Office Files and PDF
    htttp://www.e-iceblue.com/free-apis.html
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!