The Old Joel on Software Forum: Part 4 (of 5)

Design skills gap

I have a big design skills gap that I'd like to work on, and I'm looking for advice, on-line materials, or books to help me close that gap.

For the sake of argument, let's use the following abbreviated process model:
1. Gather and write user requirements.
2. Write technical specifications.
3. Develop architecture for application.
4. Break design into deliverable units (e.g., WBS).
5. Design and code a unit from 4.
6. Remainder of process.

I've done 1, 5, and elements of 6 as needed. In these activities I've used use cases, UML, design patterns, E-R diagrams, data flow diagrams, state diagrams, and a bevy of other "design tools" and methods.

But I've never done 2, 3, and 4. Most of the software design books I've looked at focus on the modular level of design (the activities I described above). I want something that focuses on the big picture. I've looked at a few architecture books, but the one's I browsed through were very vague.

Any advice, resources, or books that one could recommend?

anon
Monday, April 5, 2004

I get the impression you will not be doing # 5 anymore? If so, I would guess the amount of documentation does not matter so much and you wouldn't be asking this.

So, there are two ways to answer this. First, you need to spell out a high level vision of how you think this thing should be constructed. Basically it is important to segment the solution into these components. Next you...

... Detail out what is important to you. Some things you may not care how they are implemented and some things you may care very much about.

and/or

... Ask the people doing #5 what they would like to see. If they have done this before (i.e. they are contractors) they may have a very good idea on what works for them.

At the end of the day, you just need to know who will be consuming your documents and justify their purpose.

This is not the answer, but part of it.

m
Monday, April 5, 2004

eXtreme Programming (God, I hate that stupid name) has some reasonable ideas on this process. Take a look at the "XP" Web site: http://www.extremeprogramming.org/

Good luck.

Vans Davis
Monday, April 5, 2004

No, I'm still doing #5. I'm somewhere between a junior to mid-level programmer, but I don't want to be forever. I've developed small apps on my own, but not larger ones.

I'm in the process of developing a larger one as a personal project, but it hasn't gone to smoothly.

I think that my #1 problem with designing a larger program is that I look at it and think, "My God, where do I start?"

The one I'm working on has grown piecemeal. I decided to do incremental development. But there were decisions (or the lack thereof) made up front that cost me, so I ended up having to backtrack and make changes to the core. Now it's gotten to be such a mess that I'm thinking this is the "write one to throw away".

I need that "vision" thing. [Can I buy it in bottle form? :-)]

anon
Monday, April 5, 2004

You might want to take a look at Martin Fowler's "Patterns of Enterprise Application Architecture"

This will help with the designing and "breaking down" of an application.

What is your primary language? If we knew that, we could probably recommend some good architecture, design or pattern books that are more specific to your language.

Mark Hoffman
Monday, April 5, 2004

Check the following articles on Object Mentors site by Robert Martin.

My experience is my thinking and designs changed a lot after studying those articles. Its a mandatory reading for my teams. Usually, it gives a common vocabulary to team during design discussions.

1. Principles and Patterns
2. The Open Closed Principle
3. The Liskov Substitution Principle
4. The Interface Segregation Principle
5. The Dependency Inversion Principle
6. Stability
7. Granularity

Link to page where you will find the articles is given below
http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles

Nitin Bhide
Tuesday, April 6, 2004

imho
most of #3. shoud be done while doing #5.

I've seen too many unusable frameworks.
because the assumptions made in 3 were totally wrong.

anonymous
Tuesday, April 6, 2004

The reason you don’t see much documentation about steps 2, 3 and 4 is that companies are reluctant to share this kind of private information. I’ve gone looking for published sources before and there simply aren’t any.

The best book on “the big picture” I could suggest is “A Practical Guide to Enterprise Architecture” by James McGovern et al. But frankly, most of us learned by doing.

I’m a little concerned at how you could have possibly done steps 1 and 5, without doing the intermediate steps. It sounds as though you’re working in a bureaucratic organisation that divvies everything up into tiny parts. Even in such places, I’ve generally found that the specs and architecture are so badly written that I’ve ended up having to go back and redo the work, starting with 1 (or earlier if possible).

My best suggestion would be to take an existing project and perform steps 2 through 4 on your own from the user requirements. Then compare your version with the version you were given and decide why they’re different.

tw
Saturday, April 10, 2004