Subject: A thought about methodologies and architectures and patterns

From: Omer Zak <[email-masked]>
Date: Sat, 26 Oct 2002 18:26:06 +0200 (IST)

When I was younger and the Internet was (much) smaller and poorer, and the
main way to learn about things was to read ink patterns on dead woods, in
the form of books and journals - people were proposing various software
development methodologies, like "structured programming", "server-client",
"object orientation", "pattern based software development".

Then when I actually started working on solving a real life problem using
software, I invariably found that the problem does not always map well
into one of those methodologies.

There was this algorithm, which could be implemented without violating the
sacred laws of "structured programming", but there was that one tiny
place, where a good heretical 'goto' statement would have made things much
much more simple.

There was that problem, which had some objects, but there were parts,
which looked like a jelly or a fog or a very long pipe, and which didn't
have a natural mapping into objects. 

And there were projects, which were natural candidates for an hybrid of
methodologies - both "object oriented" and "data-driven".

I often felt that my mind is constrained by the meta-methodology of having
to choose a methodology and being strict with following its rules at any
cost.

Now I think that a better meta-methodology for software development is as
follows.
After defining your problem, choose a Methodology which matches about 90%
of the project.  Be prepared to deal with the 10% which don't match the
Methodology.  Document where you deviate from the Methodology and why.

This is like writing a software project in C++, but dropping into assembly
language where you need to be intimate with hardware.
                                             --- Omer
WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html

---

From: guy keren <[email-masked]>
Date: Sat, 26 Oct 2002 23:57:36 +0200 (IST)

> to choose a methodology and being strict with following its rules at any

the limitation was there only because you chose for it to be there. if you 
properly document your code, and your architecture and top-level design, 
it does not realy matter what "foreign" methodology you follow - as long 
as it makes sense.

> Methodology.  Document where you deviate from the Methodology and why.

you need to document all your system's architecture regardless of the 
methodology and any external formal 'constraints'. it doesn't realy matter 
if you follow a strict 'object-oriented' design, or a strict 'structured' 
design, or any hybrid which makes sense - as long as your design makes 
sense.

> language where you need to be intimate with hardware.

the fact that i write something in C++, does nto mean i have to do 
anything booch or his gang tell me to do - as long as i document my design 
without assuming any 'deep methodological' knowledge on behalf of the 
reader. this is why i never write "this code follows the bridge patter" or 
"that code follows the fly-weight pattern" - when explaining this in few 
words is usually clear enough and sufficient. one may use those buzwords - 
but only together with an explanation - not instead of it. assuming all 
good programmers know these things in these terms is the sure way into 
writing code that cannot be maintained properly in the future.

and when i do find some code that uses this in the documentation, i just 
think to myself - "eize faltzanim"...

-- 
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy

---

From: "Nadav Har'El" <[email-masked]>
Date: Sat, 26 Oct 2002 23:51:52 +0200

On Sat, Oct 26, 2002, guy keren wrote about "Re: [hackers-il] A thought about methodologies and architectures and patterns":
>..

There's a known condition that often inflicts managers, the "bike shed"
condition. See the following jem from the freebsd-hackers list in 1999:

http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers

In short, the idea is that most times managers cannot understand what
exactly you are coding, or cannot find the time to understand it. But
some things are easy for them to understand: for example it's much easier
for them to tell you "you must program using design patterns!" rather than
"hey, you have a bug in that specific class over there". It's easier for
them to mention the "fly-weight pattern" without thinking through how well
this pattern actually fits the problem at hand. You can think of the name
"fly-weight pattern" as an "executive summary" of a real explanation of
what the heck that specific part of the program is doing.

-- 
Nadav Har'El                        |   Saturday, Oct 26 2002, 21 Heshvan 5763
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Sign in zoo: Do not feed the animals. If
http://nadav.harel.org.il           |you have food give it to the guard on duty

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 27 Oct 2002 06:01:17 +0200 (IST)

> place, where a good heretical 'goto' statement would have made things much

I don't think Structured Programming means absolutely no gotos. In fact I
believe Knuth demonstrated otherwise in his article titled "Structured
Programming using Goto Statements". Sometimes using gotos will make your
code much more structured than without it.

Regards,

	Shlomi Fish

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"