Re: Design for Cocoa (was Re: Can a subclass of NSDictionary do this?)
Re: Design for Cocoa (was Re: Can a subclass of NSDictionary do this?)
- Subject: Re: Design for Cocoa (was Re: Can a subclass of NSDictionary do this?)
- From: Michael Latta <email@hidden>
- Date: Thu, 24 Jul 2003 10:06:10 -0700
I do not see this as an exception to the rule.
1) Design-first projects work best where you can hire domain experts
that are programmers. For example compilers, accounting systems,
things that have been done before with limited differences from your
requirements.
2) Test-first projects work best where there are no domain expert
programmers available. This can mean UI or art where there will never
be experts due to the nature of the problem, or in fields where there
may be no domain experts at all.
In addition I would say that the XP style of development leaves as
artifacts the test cases (as automated requirements definitions), while
the design based development leaves paper designs. The value in the
former is clear, but must be maintained to reflect requirement changes.
The value in the later is communication within the team, and to new
hires. XP tries to address the training communication issue with pair
programming.
In the end it all does come down to economics. Can you afford to have
a system that is not thoroughly tested? Can you afford to have a
system where the design is not documented enough for new hires to
understand the work done to date? What level of new hire will you
require based on the artifacts you leave behind. Will you take the
time to fold into the code lessons learned before the code calcifies?
The only real problem are projects that fail to plan their activities
enough to reach their goals, and fail to leave behind artifacts
sufficient to maintain the work, and train new hires. These projects
are doomed to failure, in the short or long term.
Michael
On Thursday, July 24, 2003, at 05:17 AM, Tim Ramsey wrote:
On Thursday, Jul 24, 2003, at 05:59 Europe/Amsterdam, Tim Ramsey
wrote:
Suppose I am building a complex mathematical/logical algorithm (one
of the things I do). Detailed design is very important here because
poor planning and/or bad data structure choices can make life a
nightmare and may make the job impossible. You can paint yourself
into a corner where you find yourself building and rebuilding
endless code and getting nowhere. Flow charts and data structure
diagrams are great in this situation, and if they look like an
explosion in a spaghetti factory, start over. A great design will
achieve a certain inevitable simplicity, even for a complex problem.
It will also run much faster than a poor design. I have constructed
optimized designs for kludged up systems that reduced runtimes by
factors of over 200 in extreme cases.
Well, here a real example. Many years ago, I was doing computer aid
protein folding. Horrible force fields, no papers/text books where to
look for ideas, chemistry, fuzzy biology, NMR spectra - all ugliness
at once. We wanted to as questions like: "What if we mutate this
amino acid", or "Where should we put a sulfur bridge in order to make
the enzyme termostabile".
We went to a greek restaurant, and when the ozo was served, we start
brainstorming. We end up with a "soup" metaphor (our architecture so
to say), and next day we start wildly coding with not a single line
of design! Several years later, we end up with what is now one of the
standard software packages, and 2.7M lines of very well structured,
maintained, and extremely readable software.
Rafactoring, Test-First-Development, and Pair Programing were the
keys to success. At the end we had about 15 pages of design document
written for newcomers...
BTW, this story started 15 years ago...
have fun
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196
You may remember I said someone would find an exception to my
examples. I hear you pointing out that a detailed design approach is
not very appropriate when the problem area itself is under > exploration.
My fundamental point is that the problem dictates the best solution. I
don't believe there is one single approach that is always best. When
we take on a particular methodology as a religion, we do ourselves a
disservice because we close our minds. We cease to be able to take
advantage of the latest developments and lose our creative edge.
Conversely, if we are always chasing the latest method, we fail to
take advantage of what we have already learned.
--
Tim
"To invent, you need a good imagination and a pile of junk."
--Thomas Edison
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.