Discussions

News: The Top 10 Elements of Good Software Design

  1. The Top 10 Elements of Good Software Design (30 messages)

    "You know you've achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away" - Antoine de Saint-Exupery

    Much is spoken of "good design" in the software world. It is what we all aim for when we start a project, and what we hope we still have when we walk away from the project. But how do we assess the "goodness" of a given design? Can we agree on what constitutes a good design, and if we can neither assess nor agree on the desirable qualities of a design, what hope have we of producing such a design?

    • 10. Considers the Sophistication of the Team that Will Implement It
    • 9. Uniformly Distributes Responsibility and Intelligence
    • 8. Is Expressed in a Precise Design Language
    • 7. Selects Appropriate Implementation Mechanisms
    • 6. Is Robustly Documented
    • 5. Eliminates Duplication
    • 4. Is Internally Consistent and Unsurprising
    • 3. Exhibits Maximum Cohesion and Minimum Coupling
    • 2. Is as Simple as Current and Foreseeable Constraints will Allow
    • 1. Provides the Necessary Functionality
    Read the full article at The Top 10 Elements of Good Software Design

    Threaded Messages (30)

  2. I think point #7 i.e. Selects Appropriate Implementation Mechanisms is not that critical initially if I have very pluggable design blueprint.

    I might not have the most suitable implementation mechanism in the first iteration itself. Better implementations can be substituted during the evolution of the app.
  3. I think point #7 i.e. Selects Appropriate Implementation Mechanisms is not that critical initially if I have very pluggable design blueprint.
    I think point #7 is correct by definition, a common theme with several elements here. How would this sound as an element of good software design: "Select Inappropriate Implementation Mechanisms"?

    The article contains some interesting tips for software newcomers or developers who are stuck in a code 'n' fix mode of working. However, many statements here are of the motherhood variety. "Provides The Necessary Functionality"???

    Tell me how to do all this, Mr Ed. Yes, experience would indicate team sophistication matters. And yes, this might be news to some people. But really, it would be a lot more useful to tell me *how* it matters and what I should do about it ... what are the patterns that I can use to deal with these truisms?
  4. Taste for Makers[ Go to top ]

    A very nice discussion about good design. Recommended.

    http://www.paulgraham.com/taste.html

    A summary:

    Good design is simple.
    Good design is timeless.
    Good design solves the right problem.
    Good design is suggestive.
    Good design is often slightly funny.
    Good design is hard.
    Good design looks easy.
    Good design uses symmetry.
    Good design resembles nature.
    Good design is redesign.
    Good design can copy.
    Good design is often strange.
    Good design happens in chunks.
    Good design is often daring.
  5. IMHO the issue of understanding the team's skillset is crucial when selecting implementation technologies, setting the level of abstraction in design and the tools used for development.

    I often see architecture and design plans that are simply not cut out to match the size and skill of the team and the level of resources that the company is willing to invest in the project.
    Too many smart people often forget that doing design is not like doing academic research and that the robustness of solution must match the allocated resources.

    When starting projects this should be one of the first things to consider.
    Yuval.
  6. Couldn't agree more. What's really interesting about this list is that no fewer than 2 of the 10 points (and arguably a couple of others) are more straight-up team and project management issues as opposed to typical "system design" activities.

    The "M" word starts to become more of a recognizable factor for goodness, it seems. :-)
  7. I think that smart project management results in design, tools and code that matches the requirements and provide business value.
    Developers should think about aiming to fulfill requirements, but sometimes this is forgotten and replaced by the fun of toying with a cool new library/technology/design concepts (and yes, it is fun!)

    Many Agile methods are really about project management, because software is really not just code, it is people, thoughts, politics and processes.
    Good design concepts are essentials, but they should come second to smart project tactics.

    Yuval.
  8. I also agree that considering the skill level of the team is extremely important. But it is not a matter of the quality of the design.
    It is a matter of an appropriate project setting and management.
    Consider a statement like "This system has a bad design because we
    can not understand it well." The matter is, good design is good regardless of
    the sophistication of the team, but occasionally it might not work. It is the
    resposibility of the project management to find a balance between the good design and the avalable set of people.
  9. Too many smart people often forget that doing design is not like doing academic research and that the robustness of solution must match the allocated resources.When starting projects this should be one of the first things to consider. Yuval.
    Yes, this is about risk managemet. Open source projects are good for research and innovations, but conservative architecture has a lot of advantages too.
  10. Yes, this is about risk managemet. Open source projects are good for research and innovations, but conservative architecture has a lot of advantages too.
    Why do u think open source projects are risky? What about different frameworks that are used in many live systems rightnow(Struts, Tapestry etc). How about JBoss do you think that will apply only to academic settings.

    In my opinion architecture(not necessarity conservative) and opensource projects can sure go together.

    Please don't mislead people.
  11. I do not said it, you just understand it tis way :)
    Open Source is better for innovations, it reduces risk (more people can review it) and one of ways in not open project is to use to more conservatyve ways to
    to reduce risk. Is it not clear ?
  12. Lets consider some of today's products marketed by top companies:

    IBM's WSAD is very much eclipse. IBM also use apache axis, and practically every major vendor (BEA doesn't) uses apache.
    More and more vendors are willing to contribute their code to the open-source because they believe it will be useful for them in the long run.
    Struts is also a successful Open Source, and any major IDE supports it (to a level).

    Many respected ISVs bundle JBoss, myself and such.

    Obviously, there are many bad open-source project as they are many bad commercial products.

    So, to say "Open-source is a risk" as general statement, is not that accurate.
    If its good use it, if its not dump it - commercial or open-source, the rule is the same.

    Yuval.

    PS: Log4J, Commons-Logging, Xerces, Hibernate, JUnit....
  13. Sorry,
    i wanted to say mySql, not myself:

    "Many respected ISVs bindle JBoss, mySQL and such".

    Thats it,

    Yuval.
  14. I agree completely. The #1 success or failure factor in any project is the team, and you have to design the project around them (and not try to force it the other way around). The most spectacular failures I've seen all involved giving the wrong sort of work to the wrong team (often, it was with technology they'd never heard of, let alone used before).

        -Mike
  15. I think number 3 is easier said than done.

    Many systems startout with 3 as a main objective. But it not simply practical.
  16. #10: Considers the Sophistication of the Team that Will Implement It

    Ah yes. Really smart, smart developers/architects sometimes forget that, while the design might be really good in their head, and might be well understood in their head, they forget that an architecture or a design idea fails if it cannot be understood by a majority of the team who will be using it. It then becomes a bad/tedious design idea. Design reviews definitely help with this.

    #8: Is Expressed in a Precise Design Language

    I'm surprised that UML isn't used like it should be, although, I do remember first using it and misusing certain types of diagrams to clearly document an idea.

    #6: Is Robustly Documented

    IMHO, if a design can be easily documented in a Unit Test, then the design is probably (though, not always) a decent design to start with. If it can't, or it can't be articulated easily in a detailed design doc, then it's probably (though, not always) too complex.
  17. #10 is a sad reality[ Go to top ]

    10. It's unfortunate, but true. I think that it should be the other way: "forms a team capable of implementing the design". Unfortunately, it's impossible, usually.

    Ideally, we shouldn't be constrained by sophistication of them, but only with its size. In reality, we meet all sorts of people in the field. Some should be doing anything else but code :)
  18. #10 is a sad reality[ Go to top ]

    10. Considers the Sophistication of the Team that Will Implement It<
    Yes, unfortunately that is something a design needs to consider. And not only the implementation team but also the maintenance team (which may well be different and often has a lower skill set). And this has been true for many, many years.

    >9. Uniformly Distributes Responsibility and Intelligence< That's not much more than a sound-bite, IMO. What does it really mean?

    >8. Is Expressed in a Precise Design Language< Overkill for a lot of situations and not really about the design itself.

    >7. Selects Appropriate Implementation Mechanisms< Another sound-bite. "appropriate" is very subjective.

    >6. Is Robustly Documented< Again, nothing to do with the design per se. It also seems to preclude XP.

    >5. Eliminates Duplication< OK.

    >4. Is Internally Consistent and Unsurprising< Good advice but still subjective and hard to measure.

    >3. Exhibits Maximum Cohesion and Minimum Coupling< Hmm, that sounds a bit absolutist (and a bit elitist). It can also work against the principle of simplicity - ensuring maximum cohesion and minimum coupling can complicate a design in order to achieve the desired levels of isolation.

    >2. Is as Simple as Current and Foreseeable Constraints will Allow< Bit of a sound-bite and could well be at odds with #3.

    >1. Provides the Necessary Functionality< Well, duh! Yeah, that's the most important point, that it actually solves the problem it's supposed to.
  19. Yes these are all good ideas. But the reality is that each of these have counters. #1 for instance sounds great but how many shops actually know how to gather requirements adequately and how many are driven by over-promised BS from marketing so that "the necessary functionality" is not what a customer wants but what some marketer interprets as a need. #10 has to be considered but if you scale the technology to suit the expertise of the team, you may create an architecture that is not suitable to the performance and/or scalability requirements of the system. If you choose the technology to suit the application and have a team without expertise to exploit the advantages, then you will have the same trouble. #8 is a pipe-dream. A precise specification language is one that is completely unambiguous and formally verifiable. For all but the simplest applications, this is not feasible. The very fact that we mostly use English to communicate (note that our programming languages all use English keywords) suggests that ambiguity is built in to the communication mechanism. And I could go on...
  20. a different list[ Go to top ]

    1. the design meets the requirements (functional and non-functional)
    2. the design is clean
    3. the design is efficient
    4. the design is easy to use

    Cleanliness embodies:

    consistency - do similar things in similar ways
    orthogonality - do not link what is independent and do not separate what is dependent
    propriety - don't define the same thing twice, don't add unecessary things
    generality - do not impose unecessary restrictions

    This is all from a PhD thesis by Martin van Sinderen.
  21. There's really nothing new here. Therefore, I must ask, why do I care what this guy thinks? Who is he anyway? I don't see any credentials, CV, bio, or even a real name on his site.

    Seems to me his blog is more of a personal crusade against XP than anything. The only hit I get on Google for his email address, r dot bailey at bigpond dot net dot au, is him being a troll on comp.software.extreme-programming.

    Yawwwwn .....
  22. Shit[ Go to top ]

    All bullshit.It just a text-book and stero-typed speaking.Only #4 make some real sense.
    Software design need proper&feasible process, not those seen-everywhere guideline. Could TSS do not waste my eyes posting these kind of naive or academical article?
  23. process?[ Go to top ]

    SW development is not a fast food production. Process can't guarantee quality. Right people do right software regardless of the process. wrong people do wrong software regardless of the process.
  24. process?[ Go to top ]

    SW development is not a fast food production. Process can't guarantee quality. Right people do right software regardless of the process. wrong people do wrong software regardless of the process.
    No sh*t. Can you specify please the size/number of developers in the bigest project you've been involved in ? I've seen right people managed like sh*t and they weren't producing the right software if anything. Also I've seen "wrong people" smartly managed and they were producing the right software in time and on budget all the time.

    I don't quite understand what do you mean by "wrong people" though.

    You can't get the best developers all the time. But you can get your developers to do it right.
  25. process?[ Go to top ]

    SW development is not a fast food production. Process can't guarantee quality. Right people do right software regardless of the process. wrong people do wrong software regardless of the process.
    Crazy! That just means you are using wrong processes. I am not talking about the likes of CMM, CMMi, *MM models. Identifying what is the "intent" of what these *MM models say and trying to work that out is the MOST EFFICIENT way for software development. 90% of the *MM practitioners are just preachers and they try to interpret it without ever having seen how a project runs. So I would say go by the intent of what the standard models say and that would result in excellent software design. Processes are the key. Try doing a software project with no configuration management process in place. Have you?

    -Sanjay
  26. So I would say go by the intent of what the standard models say and that would result in excellent software design. Processes are the key. Try doing a software project with no configuration management process in place. Have you?-Sanjay
    Good designers will do good design. If you are not a good designer it doesn't matter what process/methodology is used. You'll make a bad design. That's it.

    As to configuration management: it has nothing to do with design. It's like a supporting service, you know, like janitors, for example. Yes, it sucks without a good toilet, but it won't make a good design on its own.

    CMM/ISO and other stuff like that has nothing to do with design. These certifications are used by consulting companies to pretend that they have "processes" and can produce quality software. I guess all outsourcing companies try to get one of these certifications now. Mostof them produce crappy code anyways.
  27. process?[ Go to top ]

    Good people is an factor of success,but not as important as process.Process i refered here is not those CMM stuff,it's operable practice like TDD, FDD, Nightly build & constant integretion, how document&requirements synchronized with design. As someone said, a team composed of ten excellent guys may as match as (a good PM+a good Team leader+ 5 normal programmer).
    So my point is the operabality, senario, tailor of rules, the process of design is much like making a cocktail---adjust those rules to fit the taste of project
  28. KISS, keep it simple stupid[ Go to top ]

    The list is just OO-bullshit or academic dreams.

    The only guaranteed way to success is to keep the projects as small as possible but still more than 1 person, keep down the number of layers, and make a simple stupid design and implementation.

    Research shows that real OO-projects are more expensive to create and twice as hard as debug.
  29. 10. Considers the Sophistication of the Team that Will Implement It

    A good design is alway simple...yet the implementation can use simple or complex constructs.

    9. Uniformly Distributes Responsibility and Intelligence
    8. Is Expressed in a Precise Design Language.

    How about C#,Java or C++ ?

    7. Selects Appropriate Implementation Mechanisms

    Not a design issue

    6. Is Robustly Documented

    How much is enough and if it simple then would it need elaborate documentation

    5. Eliminates Duplication

    Implementation....

    4. Is Internally Consistent and Unsurprising

    Yes I agree

    3. Exhibits Maximum Cohesion and Minimum Coupling

    Universal Truth

    2. Is as Simple as Current and Foreseeable Constraints will Allow

    Should be done on Case to case basis

    1. Provides the Necessary Functionality

    That can only said when the first Release is in the market.
  30. I would like to suggest some principles to help:

    Liskov Substitution Principle (LSP)
         http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple

    Dependency Inversion Principle (DIP)
         http://c2.com/cgi/wiki?DependencyInversionPrinciple

    Open-Closed Principle (OCP)
         http://c2.com/cgi/wiki?OpenClosedPrinciple

    Law Of Demeter
         http://c2.com/cgi/wiki?LawOfDemeter

    n Layer Architecture
         http://c2.com/cgi/wiki?FourLayerArchitecture
         With no ciclic dependencies between layers
    Modular (cohesive and loosely coupled modules)
         http://www.manageability.org/blog/stuff/six-operators-of-modularity

    IMO
  31. With the emergence of Aspect oriented development is the concept of cohesion still important? If system wide functionality is distributed across several method calls (as in the aspect oriented paradigm) does this not equate to low cohesion? I think that low cohesion at a method level is fine so long as there are other ways to track all system actions and use cases.