[techtalk] XP vs UML

[jenn at simegen.com]

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.

jenn at simegen.com     Jenn Vesperman     http://www.simegen.com/~jenn/