Subject: Applying TOC to the profession of programming?

From: Omer Zak <[email-masked]>
Date: Tue, 5 Mar 2002 12:22:57 +0200 (EET)

Did anyone read about TOC (Theory of Constraints), developed by Dr. Eliahu
Goldratt?  (For more information, you can google Theory of Constraints)

Basically, in each human endeavor, there is some constraint, which limits
the rate of accomplishing it.  For example, a lathe cannot remove more
than x mm metal per minute, for a given metal and certain other
process parameters.

My question is what are the corresponding constraints in software
development.  (Bearing in mind that the scope here is one of a single
programmer developing a module, not one of a group responsible for a
10,000,000 line software mega-project.)

Tentative answers and guesses:
1. The time needed to fix bugs.
2. Response time from computer.
3. Rapid access to documentation (API description, help files, source code
   comments).
4. Time to remember and integrate all considrations going into writing a
   phrase in source code.
5. Interruptions and distractions (such as phone calls).
6. Availability of high-level tools for automating repetitive tasks.
7. Number of information items, which need to be remembered at once when
   writing a phrase.

                                             --- Omer
There is no IGLU Cabal.  Once upon a time, it was an interesting subject
tu pursue.  Now it is so damn boring.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: Shlomi Fish <[email-masked]>
Date: Tue, 5 Mar 2002 19:22:06 +0200 (IST)

> 1. The time needed to fix bugs.

And the number of bugs one can avoid by knowing the pitfalls.

> 2. Response time from computer.

One of the reasons why I prefer using gcc over g++. Very important. One of
the reasons I found Delphi so enjoyable was because compilation took
virtually seconds.

> 3. Rapid access to documentation (API description, help files, source code

Or man pages and info pages... ;-) Again, the online help is a life saver
in Linux or in MSDN.

> 4. Time to remember and integrate all considrations going into writing a

Usually, I write it very quickly. It usually isn't too bug prone, (not
more than usual I believe). But I do rely on the compiler to fix typos and
the such.

> 5. Interruptions and distractions (such as phone calls).

I think programmers need to procrastinate and beat the bush a little if
you want them to produce good code. Of course, a good programmer has a
little discipline and makes sure he actually still get some work done. But
I used to have days, where I could not get too much done. And I don't feel
bad about it, because I still had a good output.

> 6. Availability of high-level tools for automating repetitive tasks.

Refactoring tools, anyone? I just split a Freecell Solver class into three
classes (with A : B = 1 -> inf and B : C = 1 -> inf), using basically
nothing but gvim. I wish I had something better for the job.

However, it did go more quickly than the first time I tried it, where I
believe I used MSVC and did not have the sense to change all the variables
at once. (nor was it very possible due to the GUIishness)

> 7. Number of information items, which need to be remembered at once when

I believe Larry Wall mentioned that a human is capable of thinking of 7
items (+/- 2) at a time in one of his lectures. That's why some very
OO-ish code is very hard to construct and understand IMO. This is not
meant as an anti-OO flames, but that's part of the reason why I like to
have a choice of not using OO if I don't need to.

Regards,

	Shlomi Fish

There is no IGLU Cabal! Or in Java:
IGLU.setCabal(new NoLugCabal());

(I actually see a much more badly constructed Java pseudo-code in the
Vipe.technion.a.i jokes mailing list. I could not help but comment,
correct and troll the poor guy who wrote it.)

> To unsubscribe from this group, send an email to:
> [email-masked]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

----------------------------------------------------------------------
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?"

---

From: guy keren <[email-masked]>
Date: Wed, 6 Mar 2002 14:00:28 +0200 (EET)

On Tue, 5 Mar 2002, Omer Zak wrote:

> Goldratt?(For more information, you can google Theory of Constraints)

not directly, thought this name was used in various contexts - so perhaps
i know about it without knowing about eliahu.

> the rate of accomplishing it.For example, a lathe cannot remove more

granted. there aer limits, which can be somehow quantized(??).

> development.(Bearing in mind that the scope here is one of a single

why limit yourself to that? to simplify the discussion? or for a different
reason?

> 1. The time needed to fix bugs.

are you refering to 'while writing a 10K lines program, how much time one
devotes to fixing bugs?'. are you refering to 'in a 10K lines program,
after adding a new feature, how long it takes to debug this feature, and
make sure no new bugs in the existing code were added?'. or are you
refering to 'if i have a single bug in a 10K lines program, how long will
it take me to find it?'.

for the first question, you can have a 'rule-of-thumb' answer, assuming
some knowledge of that programmer's history. for the others - the answer
is completely non-deterministic, at least in my experience.

> 7. Number of information items, which need to be remembered at once when

be careful not to stumble on the legendary 'mythical man-month' pitfall.
there is no strict reply here - its completely individual. a good
programmer can be 10-15 times more efficient then a mediocre programmer,
and infinitly more efficient then a lousy programmer (since the lousy
programmer will never get the job done).

thus, if you want to have more meaningful results, lets reduce the 'study
case' into 'given past info about a given programmer, what is the limit
for efficiency improvement for _this specific programmer_ ?

even this can only be measured across time (i.e. on any given day, as
shlomi pointer, one's effiency could change radically), as well as across
types of programs (if i write an application of a type i already wrote 5
times before, i'll do it much faster then if i write an application in a
field i'm completely not familiar with).

by the way, if you haven't yet read "the mythical man month" - you might
want to take a look at that book. its small, its ancient, its quite
controversial (goes to an extreme), but that's what one sometimes need to
open their mind. and you still find people who use the term 'man year'
(See, they moved from man-month to man-year) to these days.

--
guy

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

---

From: guy keren <[email-masked]>
Date: Wed, 6 Mar 2002 14:06:16 +0200 (EET)

On Tue, 5 Mar 2002, Shlomi Fish wrote:

> items (+/- 2) at a time in one of his lectures.

its nice to know that you need to refer to larry in order to learn
cognitive psychology. he is merely quoting on what psychologists have
measured. btw, the limitation is not about thinking - its about short-term
memory.

> That's why some very

here is where you simply don't grasp the basic idea of OO - data
abstraction. its a tool to allow you NOT to have to remember too many
details at once. this is where OO _helps_ you. if it distracts you - then
you haven't done your OO design properly. OO's abstraction means you take
a set of details, and turn all of them into a _single_ object. then, you
do the same for another object. then you take a few objects, and abstract
them under another single object. while doing this - you only need to hold
3-4 objects in memory, rather then all the data that _they_, in turn,
hide.

if you don't do it this way - then you're not doing OO. all the other
features (inheritance, polymorphism and the like) are just extentions of
OO.

--
guy

---

From: Shlomi Fish <[email-masked]>
Date: Wed, 6 Mar 2002 14:56:06 +0200 (IST)

> measured. btw, the limitation is not about thinking - its about short-term

I was just quoting him because I did not read it anywhere else. (actually
I overheard someone talking about it). I'm not really an expert in
cognitive sciense, but it sounds like a fascinating subject. Or perhaps
set of sciences.

> features (inheritance, polymorphism and the like) are just extentions of

The problem is that an object->method call takes at least one object out
of your mind and a &function call takes one. (pardon the Perl-like syntax,
but it makes it clearer). If your language only supports static methods
and not functions per se, you have to remember they are not connected to
the class or namespace in which they are found.

I don't like OO stuck down my throat too much and prefer languages that
give me a choice whether to use it or not. Also, I'd rather have "$a =
$b;" duplicate a string and create two copies of it, then me having to
type "a = new String(b)" or whatever it is in Java. But this is the design
of atomic values, and not really OO.

The way I see it Perl 5 was designed so that the number of objects one have
to refer to in memory is minimized. If you don't feel that way about Perl,
fine. If you think an overly OO design of a language does not cause harm
in this sense, that's fine too.

But I am entitled to my opinion.

Regards,

	Shlomi Fish

There is no IGLU Cabal! Its members can only hold up to 7 bytes in their
short-term memory at once, and the sentence "There is an IGLU Cabal" has
more.

---

From: "Nadav Har'El" <[email-masked]>
Date: Wed, 6 Mar 2002 15:14:54 +0200

> > items (+/- 2) at a time in one of his lectures.

I remember, in my previous workplace, being officially assigned to 6 (!)
different projects. This was about the limit of my multitasking abilities.

Of course, when I came home I had to switch to an entirely different working
set of processes, including trying to finish my MSc... :(

-- 
Nadav Har'El                        |      Wednesday, Mar 6 2002, 22 Adar 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |What did the Buddhist say to the hot dog
http://nadav.harel.org.il           |vendor? Make me one with everything.

---

From: Omer Zak <[email-masked]>
Date: Wed, 6 Mar 2002 15:38:56 +0200 (EET)

> features (inheritance, polymorphism and the like) are just extentions of

Data abstraction helps if you can find out everything you need to know
about an object from glancing at a single class declaration (C++
terminology) in a single header file.

However C++'s implementation of inheritance makes this impossible in the
general case.  In a deep inheritance chain, you may have to browse
arbitrary number of header files, just to find if a function was declared
as virtual somewhere in the inheritance chain.

Other OO languages, commit this sin, too.  The common denominator is that
those languages fail to require that any method inherited from ancestors
is private (not even protected) unless otherwise re-declared in the
present class's interface declaration.

In other words, Shlomi does have a point.  Maybe not about the original OO
idea, but about the way it is implemented in most OO languages.
                                                             --- Omer
                                             --- Omer
There is no IGLU Cabal.  Their flagship project - The Magnificent Tower of
Inheritance was built up, like the Tower of Babel.  However, TMTI met the
same fate of the Tower of Babel, due to abuse of data abstraction
principles in the language used (which was based upon OO, patterns,
Demeter's Principle, anti-patterns, principles of thought, theory of
neuronic data processing, and quantum computing based NP-complete
oracles), each of the workers in the project lost understanding of his
interfaces with his fellows.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: Omer Zak <[email-masked]>
Date: Wed, 6 Mar 2002 14:41:01 +0200 (EET)

> why limit yourself to that? to simplify the discussion? or for a different

To simplify the discussion.
Also, if we identify the constraint of a single programmer, this may help
us identify constraints in mega-projects.

By the way, anecdotal evidence is that in mega-projects, the constraint is
the need for programmers to communicate with each other.  One cannot
progress with his code without getting clarification to that obscure point
about interface X34Y57Z91 between his module and that module, which will
run on the quantum computer beyond the hyperspace barrier, on the other
side of the galactic wireless link.

I suspect that the single-programmer constraint is really similar to the
above:  a programmer needs to communicate with himself (or rather, with
his memory) all the time.

> is completely non-deterministic, at least in my experience.

I mean the last alternative.  The actual time does vary widely.  But there
are averages and standard deviations...

> > 7. Number of information items,which need to be remembered at once when
> >writing a phrase.
>

What makes the efficient programmer much more efficient than the mediocre
one?  What thought processes does he employ, that the mediocre programmer
doesn't employ?  What pieces of thought does he accomplish much faster
than the mediocre programmer?  Does the efficient programmer have the same
constraints (in the sense of TOC) as the mediocre ones?

> for efficiency improvement for _this specific programmer_ ?

No, what is the constraint which puts a limit for his efficiency
improvement?  If the constraint can be broken, then his efficiency will
take a quantum leap.

Example of breaking a constraint:  mega-projects, which are executed by
a small group, hence breaking the interpersonal communication constraint.

                                             --- Omer
There is no IGLU Cabal.  First, we need to break at least 53 constraints,
and only then will we have the satori experience needed to start the IGLU
Cabal.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: guy keren <[email-masked]>
Date: Thu, 7 Mar 2002 14:52:30 +0200 (EET)

> cognitive sciense, but it sounds like a fascinating subject. Or perhaps

in the technion, the department of 'teaching science' (or 'science
teaching'?) has a course named 'cognitive psychology. the course, as is
tought, is a bit shallow, but scanning its contents could give you an idea
of which books to look for, if you're interested.

> the class or namespace in which they arefound.

don't blame the language - blame yourself. if you're using static methods
not related to the class - its your problem, not the language's problem.
indeed, java's "main" is an exception - but then again, put it in a class
of its own, called 'Main', and you've got no problem again.

> type "a = new String(b)" orwhatever it is in Java. But this is the design

we were not talking about having OO stuck down your throat. we were
talking about OO and short-term memory. but you keep puling towards your
hatred towards OO, no matter what the topic is. and indeed, in this case,
you're talking about something not related to OOP. in fact, in C+ you can
still have

   string b = "helo";
   string a = b;

only difference between this and your beloved perl is the strong-typing.
and strong-typing got nothing to do with OO - it just happens to be
another feature of C++. don't like it? stay away from C++, but don't
critisize OO for being 'strongly typed' now.

and i know these are not the same (heap storage vs. stack storage) but in
your context, they give you the same thing.

> to refer to in memory is minimized.

perl 5 was never _designed_. it simply _happened_. the usage of references
in it is a kludge, and makes the code quite very unreadable. i've done
some programming with them now, and i keep failing to remember the syntax
needed to dereference various types of objects. this was not the case in
perl 4. example:

   $#{@$pre_struct_param_names_ref}

this ^^^^ is the ugly syntax i managed to come up with, of counting the
number of elements in an array passed by reference. and it took me a lot
of trial-and-error to find this syntax, since i failed finding it in the
man pages. ofcourse, i never manage to remember it. this is, ofcourse,
just one example.

> If you don't feel that way about Perl, fine. If you think an overly OO
> design of a language

objection. any kind of OO design, except that of perl, looks 'overly OO'
to you.

> does not cause harm in this sense, that's fine too.

i prefer the way OO was done in C++, to the way it happened in perl 5.
when i use perl - i don't use objects. i use references only to avoid the
ugly kludges i had to use in perl 4, for handling mappings of
one-to-many and many-to-many. and i do so with a heavy hart, and a lot of
copy & paste. if it helps you, i have a similar problem with usage of
templates in C++ :)

> But I am entitled to my opinion.

and i'm entitled to flaming it once in a while, since you use your
'entitelment' quite very often :)

--
guy

---

From: guy keren <[email-masked]>
Date: Thu, 7 Mar 2002 15:07:56 +0200 (EET)

> terminology) in a single header file.

sounds _almost_ reasonable.

> general case.In a deep inheritance chain, you may have to browse

don't have deep inheritance chains - i know i usually don't. as i said in
a pervious post (that was probably dumped into the bit bucket ;)  ),
inheritance is NOT the best way of code reuse. containment is how i
usually go with. this is, btw, the way you do object-oriented programming
in C as well.

btw, this splitting into files isn't mandatory - you could have all
classes in a single file (thought this doesn't make it any better). in new
IDEs, you can have the list of available methods when you "stand" on an
object of a given class (ofcourse, _we_ don't use those IDEs, right? ;).

> Other OO languages, commit this sin, too.The common denominator is that

in objective-C, _all_ methods are virtual, so you don't have this problem
at all. in fact, programming in objective-C was fun (except for the lack
of proper debugging tools) because every object is an 'id', there is a
single super-class, and there is no strong typing what-so-ever (shlomi
might love objective-C for this reason).

> In other words, Shlomi does have a point.Maybe not about the original OO

if one has a point about something - one should not use this point to
dis-credit _another_ thing. and still - its not the language alone - its
mostly the programmer. nobody is forcing you to use inheritance, exept for
3rd-party libraries.

--
guy

---

From: Shlomi Fish <[email-masked]>
Date: Thu, 7 Mar 2002 15:06:48 +0200 (IST)

Guy, thanks for the Cognitive Science link. There's also a Usenet group
about it, which I know of and some web resources.

In any case, if you'll excuse me I think I'll skip the rest of this Perl
5 vs. C++ OO-wise holy war. I have better things to do than argue with
you about it.

Regards,

	Shlomi Fish

There is no IGLU Cabal! They wrote a web servlet in Perl, C++, ANSI C,
Fortran, Common LISP, Haskell, Pascal and Intercal only to discover it was
not needed in the first place, because there was one written in Python
10 seconds of Googlizing away.

---

From: Oleg Goldshmidt <[email-masked]>
Date: 07 Mar 2002 17:55:15 +0200

> 5 vs. C++ OO-wise holy war. I have better things to do than argue with

No, no, you won't get off the hook so easily! Before you switch to
Rindolf development, please go over the archive and tell us who
started the jihad in the first place. We have forgotten... ;-)

-- 
Oleg Goldshmidt | [email-masked] 
[Lisp] is the only computer language that is beautiful. 
                      - Neal Stephenson

---

From: Oleg Goldshmidt <[email-masked]>
Date: 07 Mar 2002 17:53:26 +0200

guy keren <[email-masked]> writes:

> usually go with. 

Guy, this looks like the same kind of absolute that often comes up if
various flamebaits here and on Linux-IL, and I would expect you, of
all people, to know better. 

You certainly know at least as well as I do that inheritance and
containment model different relationships between objects (is-A,
has-A, holds-A, etc), and it does not make sense to say that one is
better than the other. One should use what is appropriate.

---

From: Shlomi Fish <[email-masked]>
Date: Thu, 7 Mar 2002 18:54:36 +0200 (IST)

> started the jihad in the first place. We have forgotten... ;-)

Fine, I admit I expressed my lack of fondness of C++'s OOP implementation
first. You can say it's a known issue with my personality.

However, I got tired of discussing it, and trying to protect my opinions
against someone who is just as stubborn and takes the other side.

Regards,

	Shlomi Fish

---

From: guy keren <[email-masked]>
Date: Fri, 8 Mar 2002 01:51:25 +0200 (EET)

> against someone who is just as stubborn and takes the other side.

you're quite wrong here - i'm not taking the other side. i'm taking a
different side altogether - i write in perl quite much, and i like it -
after taking out the annoying features. i did the same with c++ (taking
out the annoying features), and do the same with other languages i use. i
just don't like it when people "throw the baby with the water" using this
total-reject approach. you can learn even from your worst enemies.

and its better to improve on things by seeing how _you_ can do better,
then seeing how other people could do better (i know - a bit
sefl-contradictory for this thread ;)   )

--
guy

---

From: guy keren <[email-masked]>
Date: Mon, 11 Mar 2002 13:05:04 +0200 (EET)

> all people, to know better.

please note that i didn't say "inheritance is not good and should be
avoided". i just said "not best method". i say that, because many people
only think 'inheritance' when they think of 'reuse in c++', and i wanted
to make it clear that this should not be the automatic way to do things.

> better than the other. One should use what is appropriate.

it does, since in many cases where people use inheritance, they don't do
it properly, simply because the objects that inherit shouldn't realy
inherit. there are few cases in which it is clear that there should be a
class hierarchy (GUI programs, drawing programs, etc), but even in those
cases, people tend to over-inherit classes that shouldn't be directly
inherited from one another.

inheritance has a problem of making things less flexible then when using
containment - containment makes it easier to modify the behaviour of
objects in this sense, since you can override any method you wish - not
just those that the original programmer defined as virtual. one feature i
found missing in c++ was a 'delegates' keyword, that could be used to
directly pass a method invocation to a contained object - i had to use
macros for this ;)

--
guy