|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 30
Messages: 30
Messages: 30
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
The Top 10 Elements of Good Software Design
"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
|
|
|
Message #122788
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Top 10 Elements of Good Software Design
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.
|
|
|
Message #122791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
10. Considers the Sophistication of the Team that Will Implement
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.
|
|
|
Message #122797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
10. Considers the Sophistication of the Team that Will Implement
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. :-)
|
|
|
Message #122806
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Top 10 Elements of Good Software Design
I think number 3 is easier said than done.
Many systems startout with 3 as a main objective. But it not simply practical.
|
|
|
Message #122807
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
10. Considers the Sophistication of the Team that Will Implement
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.
|
|
|
Message #122811
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
10. Considers the Sophistication of the Team that Will Implement
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
|
|
|
Message #122819
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Top 10 Elements of Good Software Design
#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.
|
|
|
Message #122837
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
10. Considers the Sophistication of the Team that Will Implement
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.
|
|
|
Message #122840
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
#10 is a sad reality
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 :)
|
|
|
Message #122846
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Top 10 Elements of Good Software Design
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?
|
|
|
Message #122847
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: The Top 10 Elements of Good Software Design
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...
|
|
|
Message #122854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
a different list
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.
|
|
|
Message #122855
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Top 10 Elements of Good Software Design
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.bailey@bigpond.net.au, is him being a troll on comp.software.extreme-programming.
Yawwwwn .....
|
|
|
Message #122864
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Shit
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?
|
|
|
Message #122876
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
process?
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.
|
|
|
Message #122878
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Project management is everything.
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.
|
|
|
Message #122880
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
process?
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.
|
|
|
Message #122885
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
10. Considers the Sophistication of the Team that Will Implement
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 ?
|
|
|
Message #122901
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
process?
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
|
|
|
Message #122909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Think Again:The Top 10 Elements of Good Software Design
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.
|
|
|
Message #122914
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
again, SW development is NOT process driven
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.
|
|
|
Message #122936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Taste for Makers
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.
|
|
|
Message #122947
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
#10 is a sad reality
>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.
|
|
|
Message #122991
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
process?
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
|
|
|
Message #123025
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is cohesion still important?
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.
|
|
|
Message #123135
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
KISS, keep it simple stupid
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.
|
|
|
Message #123168
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OpenSource as a risk: not black or white
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....
|
|
|
Message #123169
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Misleading typo: "Many respected ISVs bundle JBoss, myself "
Sorry,
i wanted to say mySql, not myself:
"Many respected ISVs bindle JBoss, mySQL and such".
Thats it,
Yuval.
|
|
|
Message #123319
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
10. Considers the Sophistication of the Team that Will Implement
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
