How do I learn design?

[Kim Kantola]

Hi All,
I have been doing Java Servlet coding for 3 years, starting from scratch learning Java, HTML, JDBC, XML, etc. I am at a point where I feel like I understand all the nuts and bolts of writing Java Servlet code, but am still stumped when it comes time to start a new project and design is involved. If someone gives me a designed structure, i can code it. But without someone providing a design, I have trouble making the jump from business requirements to getting started deciding how to organize the objects I will need to complete the task. I have tried reading several pattern books but the info is not sinking in.
Does anyone have any advice on how I can get over this hump, or do you think it is a matter of time and experience?
Thanks,
Kim

[Lasse Koskela]

The best source for learning is a combination of practice and literature -- the text sinks better when you get those "Doh!" moments...
One way of learning the nuances between designs could be to simply try out a number frameworks (Struts, WebWork, Spring) and get a "feel" for what the differences are and to what kind of situations each fit best. It's not a shortcut, though, far from it actually...

[Stan James]

Reading code is a fabulous exercise. There is tons of open source stuff you can look at. The problem is knowing whether any of it is "good" design or just cobbled up code that happens to work right now. That's where going to the books might be good. Robert Martin's Agile Software Development is all about improving designs in the small - a handful of classes that have to interact with each other. The examples are great. Something like J2EE patterns books would be design in the very large. The guys at the Server Side put their books online for free: I can't find the proper link but Google gave me this: http://www.theserverside.com/books/wiley/

[Kim Kantola]

Thank you very much taking the time to reply. I will take a look at the recommended book.
More replies welcome if there are any other tips out there. Thanks.

[Ilja Preuss]

I can second Robert Martin's book.
I have also heart good things about "Object Design: Roles, Responsibilities, and Collaborations" by Rebecca Wirfs-Brock and Alan McKean. I didn't read it yet, but you should be able to find the example chapter "Finding Objects" somewhere on the net...

[Kishore Dandu]

Best way is reading and applying the different proven patterns.
Three suggestions.
1) J2EE design patterns - Deepak Alur etc from SUN press.
2) Design patterns - bt Erik Gamma et al.
3) UML distilled by Martin Fowler.
Dan

[Marlene Miller]

Hi Kim. I also would like to know how to learn how to design. I am trying to figure this out.
Here is what I imagine to be the ideal way to learn how to design.
Phase 1: Seeing and analyzing good designs. You are given a problem. You first think about it and try to identify some possible components and relationships. This will help you to appreciate a solution. But you get stuck. You don�t know how to proceed. You observe and study a good solution. You implement a prototype to really understand and secure the ideas.
Next, you are given a similar problem and you borrow ideas from the design you just learned for your design.
Phase 2: Experimenting and comparing. You are given a problem. You think about it and try to design a solution. Several people do the same thing. You study the other good designs and remember their ideas. You listen to those people talk about their designs.
Phase 3: Practice and correction. Over the span of your life as a software developer, you seek out good designs. You analyze those designs and you listen to the designers talk about their designs. You present your designs to those people and receive suggestions on better ways to do things.
----
I think very few people are good at designing, very few people are good at thinking abstractly, very few people can create a meaningful story. If you are lucky, where you work one or a few people are good designers. Seek out those people and study their designs. Read their code, throw away the details and find the design. Listen to them.
Meanwhile, all you can do is to use common sense.
----
I have been following the posts on the SCJD forum looking for how people begin their solutions. I don�t see any discussion of the beginning (other than what the database looks like physically and how to read it). I don�t see any talk about identifying concepts and collaborations before thinking about implementation. Why not?
[ February 23, 2004: Message edited by: Marlene Miller ]

[Ilja Preuss]

Originally posted by Chris Daniel:
Best way is reading and applying the different proven patterns.

I would be a little bit wary with patterns. Patterns can cause as much harm as they can do good - it's quite common for beginners to overuse patterns, which results in overengineered and complex systems. I think it's much more important to understand the principles behind the patterns - if you do, you will even naturally re-invent some of them.
That's what I like about Robert Martin's book - it talks about how basic principles, patterns and practices work together to find a design where the current forces are well balanced.
Another good book about the more detailed parts of design is "Refactoring" by Martin Fowler. Reading this book is what made me start understanding what OOD/P actually is about!

[Frank Carver]

I'll let you into one of the great "open secrets" of software development.
Almost all design is really just copying.
If you have been developing Java for 3 years you should have seen a whole load of code by now. Think about how this code fited together, how well it worked, and how easy it was to work with. Which bits were easy to change and maintain? Which bits were so simply designed they never had any bugs? Which bits were easy to test, and which were hard? Which bits were boring, and seemed very like a whole bunch of other code you had worked on?
Now, learn from all this thinking. If you want to design something "from scratch", start by picking any good bits from your experience that seem appropriate to the new system, and see how far that gets you. You might just find that you can bring in so many ideas from previous projects that the rest is just your familiar ground of adding new features, fixing problems, and refactoring to keep it simple and understandable.
And guess what, if you reflect on what was good and bad about this project, you'll have more tools in your "design toolbox" for next time. Before you know it, you'll be a design guru.
As an aside, in my experience, really good developers never actually really delete any code. It's not there in the current project, but it's in a version control system, or archived on a CD, or a floppy disc. You never know when something might come in useful for another project ...

[HS Thomas]

Originally posted by Lasse Koskela:

One way of learning the nuances between designs could be to simply try out a number frameworks (Struts, WebWork, Spring) and get a "feel" for what the differences are and to what kind of situations each fit best. It's not a shortcut, though, far from it actually...

I'm trying this way at the moment using unit tests. As Lasse says , not a shortcut but at least you are not believing everything you read blindly but adding to your experience, your design toolbox.
These, in addition are proven designs to run on all platforms.
[ February 24, 2004: Message edited by: HS Thomas ]

[Kim Kantola]

Wow, I can't thank you all enough for all this great input. I am going to start taking a look at all the book recommendations and also all the recommendations for how to learn from the code I am currently working on. It seems like a lot of the time, we are coding on such a tight schedule that its hard to have the time to spend on such a thing, but I happenen to be working at a more sane pace these days, so have the opportunity to give it a go.
Thank you all again so much.

[Stan James]

Studying unit testing is a great tip! Writing code that can be tested by JUnit is not as easy as it sounds. Doing it well strongly influences the design to decouple classes (so they can be tested alone) which is almost always a good thing. The Ranch has reviewed a couple books about unit testing. Robert Martin has a series about Alphonse and a variety of mentors, and Ron Jeffries has a series (now a book) about adventures in C#. (Different language but java folk can certainly read it and the design ideas would hold up.)
http://www.sdmagazine.com/columnists/martin/
http://www.xprogramming.com/xpmag/acsIndex.htm

[Ilja Preuss]

Originally posted by Kim Kantola:
It seems like a lot of the time, we are coding on such a tight schedule that its hard to have the time to spend on such a thing

That's, in my opinion, actually the main killer of improvement. To improve, you need to take a step back from time to time, reflect on your latest experiences, discuss them with coworkers, think about new things to try in the future and perhaps even play a little bit with ideas.
(As far as I understand, that's what Tom de Marco's book "Slack" is about - haven't read it yet, though.)
Some weeks ago, we started to do Design Workshops every two weeks. All the developers from our (small) company meet for an hour or so to discuss a specific design topic - for example, a design pattern or principle. We start by discussing them theoretically and then try to connect them to our current work. It's a great way of learning, in my experience!