Michelle Murrain wrote:
> For those who've done application or OS programming as well as web
> programming, what do you see are the major differences? Major similarities.
> Which do you like best and why? I've been thinking of delving into some
> application programming, but it seems a bit daunting to me.
Ok. NOW I feel old!
The TLAs (three letter acronyms) confused me, but by listening and
grokking arguments and context, it looks like the discussion is
between:
rapidly churning out code (probably after some thought)
and
sitting back and *thinking*, an awful, awful lot, first.
It's an old argument. It pre-dates me - it probably pre-dates most
of my lecturers. (Possibly not the one who once worked on ENIAC,
though, even though ENIAC was near its retirement when he did.)
For production programming, I advocate somewhere between the extremes.
Really. :)
Speccing and designing before production have got a bad name in some
camps, mostly because they /over/-spec and /over/-design when they
try it. Or get lost in a maze of paper.
Speccing (specifying) isn't about the paper. It's about thinking things
through. In a project I'm part of at the moment, the lead hadn't thought
about whether users needed a home screen of their own - until my
task-view proposal document brought it up.
Hell, neither had I - but as soon as I viewed the project from a user's
perspective, it was an obvious need.
Plot your way through the project from every perspective you can. From
the perspective of a user doing each of the tasks you expect them to be
able to do: and making mistakes, requiring your program to allow those
mistakes to be fixed. From the perspective of a system administrator
concerned with backups and security. From the perspective of the
(end-user) company manager, wanting to know the state of their company.
That should enable you to list *ALL* the functionality that will be
required. Including the functions you overlook if you just look at it
from a programming viewpoint.
You'll probably want to write these lists down. :)
Don't touch the keyboard yet. Think about the range of ways you could
implement a program to do all of these things. Try to find the way which
seems to you to be most extendable - customers who love your system will
want to use it for all sorts of stuff. Think about deliberately limiting
the scope of your system, as well - customers who love your system will
want to use it for EVERYTHING, whether it's appropriate or not. Think
about which designs will allow you a chance for code re-use, too -
either re-using existing code or writing re-usable code.
Then make your best guess as to which design is best for the purposes of
*this* code and *this* client.
You may want to write down the options, and the reason you chose the
ones you did.
Now you can touch the keyboard.
Keep your various bits of paper nearby. When you're tempted to change
something, look at the paper. It'll help you remember why you made the
decisions you did. If you remember why you chose to do it this way, and
STILL think the new way is better - go for it. The decisions you made
are only written on paper, not carved in stone.
But write down the new decision. And why. Cause you might need that
knowledge in a day's time. Or a week's. Or five years'.
Hm. I've rambled. Hope I've rambled usefully.
Jenn V.
--
"Do you ever wonder if there's a whole section of geek culture
you miss out on by being a geek?" - Dancer.
[EMAIL PROTECTED] Jenn Vesperman http://www.simegen.com/~jenn/
_______________________________________________
techtalk mailing list
[EMAIL PROTECTED]
http://www.linux.org.uk/mailman/listinfo/techtalk
