Effective Software Design

[richfield]

Hi,

I was just wondering what everyone's view is on the statement "Methods, notations and tools can never substitute for programmer experience in achieving effective software design"

in terms of design as both a process and a product, the role of design notations and tools in supporting design and also the influence of the implementation technologies (such as programming languages and supporting libraries & techniques such as SWING, RMI & Sockets) on software design.

I'd like to get a big thread going in hearing what you all think

Look forward to reading some of your comments

Rich

 

[stevexff]

Methods are good, but within reason. They formalise some of the best practices that are used almost as second nature by experienced developers, and as such they can be a useful aid to junior developers to improve quality. For example, test-driven development is a 'good' method. However, beware of 'methods' that are solely there to provide ticks in boxes for project managers.

Notations: notations (I guess we're talking about UML here) are an excellent way to provide a graphical view of the design and workings of a system. They provide a language-independent view, and a picture is often worth a thousand words. They are useful when you come to modify an existing system, too. But the key word missing from many UMLer's lexicon is 'elided'. Booch et al are fond of this one, and it means 'left off the diagram for clarity'. How many projects have a huge spider's web diagram showing their entire class hierarchy on the wall? The only information this conveys is 'look how much work we've done, look how complicated our project is'. Each UML diagram should convey an aspect of the system, and should only contain enough information to illustrate what's going on. Most UML design tools show all relationships, methods, members, stereotypes etc. by default, on every diagram, mostly because they can. While there's no doubt that all this information should be held in the model, it doesn't have to be visible on every diagram you produce.

UML is only useful as a common communication language if all the developers know how to read it. In my experience as a designer, I have to spend as long explaining how to read the diagrams as I do explaining the design of the system.

Tools: As a designer, design tools like Enterprise Architect, Rational Rose, Select etc. are invaluable. They make the production and documentation of a design much quicker. But the real benefits are when you come to change the design - impact analysis, regenerating documentation etc. are all done quickly, cleanly, and accurately.

(Aside: design documentation is one of those 'project manager tick in the box' (q.v.) items. All projects have to have it, and typically nobody ever reads it. The 'real' design is held in the model within the tool. This can be externalised automatically in the form of generated word documents, hyperlinked HTML pages, or PDFs. Change the design? Refactor part of the code? Add an enhancement? No problem - change the model, regenerate the documentation.)

However, just because I know how to use a pencil, it doesn't mean I can draw for s@*t. Likewise, design tools do not a designer make. You can produce a poor design as easily as a good one with a tool, you'll just be able to do it quicker...

Tools can also generate code, and do round-trip engineering from model to code and vice versa. I'd like to hear feedback on experiences from anyone using this facility on a large project.

Frameworks, libraries and similar enable you to build much better applications by 'standing on the shoulders of giants'. In the same way that an architect can specify an air conditioner for a building without having to know the full details of how to make one, libraries and frameworks help us build slicker applications much more quickly by assembling existing components.

You don't mention patterns, but that's a whole other post...