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: Tim Ramsey <email@hidden>
- Date: Wed, 23 Jul 2003 22:59:43 -0500
PS - From reading your posts, I'm getting the impression that
you're doing a large amount of up-front analysis, design and
specification work before actually writing any code. Check out
http://c2.com/cgi/wiki?BigDesignUpFront for information on some
alternative ways to develop software that can work *very* well,
particularly with dynamic languages like Objective-C. I apologize
if I'm misinterpreting your posts.
From that page:
...to me the work is in design; coding is the process of converting
that into a specific computer language and typing it in, and occurs
quickly and semi-automatically...
I find that since Cocoa is so huge and complex, I can't possibly
figure out how I'm going to do something until I really get into the
documentation and start writing test code. Even after several
years, I've still barely touched on most parts of Cocoa. How can I
say how I'm going to do something if I've never done it before?
Does anyone else get the feeling that you can only create a useful
design if the libraries your using are tiny, and thus you know them
all like the back of your hand? e.g. after a few years of using
ANSI C or the STL or similar.
Last year I had a subject on object orientated design - and I've had
previous studies over the years in that area - which I just couldn't
get into. I've had it so drummed into me that I must design every
detail before writing code that now I feel guilty writing code!
Yet, if I try to design something, all I come up with are questions
- "can I use this for this problem?", "is this efficient/fast enough
for this use?", "can I put this through this to do this?", etc.
There's no way I can find of solving these without writing the
appropriate code! I understand that sometimes you need to go back
and revise your design, but when you're doing that after every new
line of code, really, what's the point of having written the [wrong]
design in the first place?
To me, programming is more of an art than a process of engineering.
If I'm going to build a house, I can apply simple techniques to
design (& test) the frames, using known values for my materials,
etc. It's all a matter of repetition - I'm not doing anything
original. I don't want to repeat myself in code. In my mind,
everything I write should be original - if it's not, then I should
have written it better the first time such that I could reuse it
now. Art doesn't have design, in my opinion. You take your idea,
and you put it onto your canvas. The vision is in your head - if
you could draw what you're going to paint beforehand, why would you
bother painting it?!?*
But, as young and stubborn as I am, I'm not [intentionally ;)]
stupid nor rebellious. Everyone who's 20 years my senior keeps
saying "design design design", and it keeps striking a sore spot
somewhere in my mind. Does anyone else feel this, or am I really
just not "getting it"?
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
* = Granted, you might do some quick object outlines prior to
picking up your brush, but I would hardly call that 'design'. Not
in the traditional sense as it relates to programming.
_______________________________________________
I'm one of these 20 years your senior guys (or more). Been developing
software for 40 years. Maybe I can shed some light on this. Many
people go hard over on detailed designs (top-down design, etc.).
Others go hard over on extreme programming, the subject I know as
rapid prototyping. I don't believe there is one true answer - the
best way depends on what you are building. I'll give examples in a
sec. The issues are also complicated by the fact that people tend to
stick with what they know, and in the old days, detailed design was
the only way to go. Just try doing rapid change cycles using batch
computing methods and punch cards - impossible. New programmers that
are used to GUIs and don't build code to solve inherently complex
problems don't see (and don't get) any value added by detailed design.
Appropriate technology works for software development just like it
works in other areas. The examples I promised:
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.
Conversely, doing detailed design in advance for a GUI is silly. This
is the place where extreme programming/rapid prototyping is perfect.
You get the feedback you need to find out if you are building what
the user wants in plenty of time to change it until it thrills
him/her. If you do a detailed design here you spend eons designing
and building only to find out you took the wrong path, and now you
are committed - delivery is approaching and you have no time to
change things that have everyone cursing you.
Note the pattern to these examples. I'm sure someone can and probably
will find exceptions, but in general detailed design can work well
under the hood where user's are dealing with a black box. They (may)
neither know nor care how it works. This is especially true if
complex logic and data structures are involved. Rapid prototyping
works well where operations are visible to the user and to you. Ever
had any "God that looks awful" moments when you just built something
- even though it worked? People can only give useful feedback for
what they see and understand. How many users could give feedback on
the internal architecture of a ray-tracing code? How many could give
feedback on how the pictures looked when the ray-tracing was done?
--
Tim
"All you are is the decisions you make. If you let circumstances make
them for you then what you are becomes very easy to estimate."
_______________________________________________
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.