Home > Archive > Extreme Programming > April 2004 > "Really Easy Methodology" by Slashdot Poster
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
"Really Easy Methodology" by Slashdot Poster
|
|
| Ed Suominen 2004-04-15, 12:31 am |
| This post [1] looked interesting as it seems to avoid the Big Design Up
Front syndrome. Any comments from an XP perspective?
> I have used UML in the past, but it is an overkill for most projects. Here
is a quick altenative which works and can be applied mechanically:
>
> 1) write all functionality down as text
> 2) scan the text and:
> a) note all nouns
> b) note all verbs
> 3) make the nouns as objects
> 4) make the verbs as methods
> 5) write a dictionary.
> 6) discard what's left.
> 7) find the common parts between classes (find base classes)
> 8) draw an inheritance diagram.
> 9) draw an ownership diagram (the object model).
> 10) make up some examples and act them out (either by yourself or with a
team) to see if anything else is needed.
>
> It has worked for me quite well in the past for most cases. You can also
repeat any number of steps any number of times desired, if cyclic
developement is required.
[1] http://developers.slashdot.org/comm...725&cid=8838134
| |
| John Roth 2004-04-15, 8:32 am |
| "Ed Suominen" <ed-no@spam-eepatents.com> wrote in message
news:luudnRHvWqjUmePdRVn-jA@centurytel.net...
> This post [1] looked interesting as it seems to avoid the Big Design Up
> Front syndrome. Any comments from an XP perspective?
>
Here[color=darkred]
> is a quick altenative which works and can be applied mechanically:
> team) to see if anything else is needed.
> repeat any number of steps any number of times desired, if cyclic
> developement is required.
>
> [1] http://developers.slashdot.org/comm...725&cid=8838134
He's still doing the design up front. All he's done is eliminated the
step of putting it into a tool that can draw pretty pictures.
The difficulty with this, as with all design up front strategies,
is that the design hasn't been tested by being reduced to working
code. It's still speculation.
John Roth
| |
| Phlip 2004-04-15, 10:33 am |
| Ed Suominen quoth:
[color=darkred]
This is what they used to do before UML.
If a methodology is "really easy", then it's more easy to design too much,
and end up with too many objects and methods. (Note that text depends on
redundancy and periphrasis, things code does _not_ need.)
Incremental design typically surprises you how soon the objects and methods
stop growing and start being re-used.
--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces
| |
| Jeff Grigg 2004-04-15, 11:30 pm |
| Ed Suominen <ed-no@spam-eepatents.com> wrote...
> This post [1] looked interesting as it seems to avoid the Big Design Up
> Front syndrome. Any comments from an XP perspective?
projects.
UML is just a notation. He's comparing apples to oranges if he thinks
the following replaces UML. XP is compatible with UML (typically
drawn on whiteboards and napkins ;-) Waterfall is compatible with
UML. RUP is compatible with UML. (What'a surprise! ;-> :-)
[color=darkred]
mechanically:[color=darkred]
These ideas are all old as dirt. Which doesn't mean that any of them
are bad. They can all be quite useful.
Let's pick on the old noun/verb trick:
Problem: Only some of the nouns used in a typical problem description
really rise to the level of being useful classes. And some nouns
*not* mentioned in the problem description turn out to be very useful
as classes. Also, some verbs turn out to be useful classes. ;-> (Go
study some Design Patterns if you don't believe that verbs can be
classes.)
"make the verbs as methods"
OK; that's nice. What classes should the methods be put upon?
(XP answers this question, but he doesn't.)
"find the common parts between classes (find base classes)"
Delegation can also be very useful. Beware of beginners who overuse
inheritance. I've noticed over the years that far from being an
inheritance *tree*, I keep looking at my best designs and seeing a
scattering of tiny independent bushes here and there. (...not
counting java.lang.Object, which is an artifact of the language.)
[color=darkred]
In other words, he's failing to offer much in terms of useful advice
or guidance as to what to do. It's like, "do something like this, and
also do other stuff if it seems right."
[color=darkred]
> [1] http://developers.slashdot.org/comm...725&cid=8838134
Nothing he said is really wrong. But I think it falls somewhat short
of being remarkably helpful or insightful.
| |
| Sean Case 2004-04-22, 10:33 am |
| In article <ITvfc.454$No1.273@newssvr16.news.prodigy.com>,
"Phlip" <phlip_cpp@yahoo.com> wrote:
> If a methodology is "really easy", then it's more easy to design too much,
> and end up with too many objects and methods. (Note that text depends on
> redundancy and periphrasis, things code does _not_ need.)
This is why we need methodologies that make it _really hard_ to design.
Sean Case
--
Sean Case gsc@zip.com.au
Code is an illusion. Only assertions are real.
| |
| Phlip 2004-04-22, 10:33 am |
| Sean Case wrote:
> Phlip wrote:
>
much,[color=darkred]
>
> This is why we need methodologies that make it _really hard_ to design.
We need to right-size the various efforts via dynamic equilibrium.
--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces
|
|
|
|
|