PyMyth: Global variables are evil... WRONG!

[Tim Daneliuk]

On 11/15/2013 09:42 AM, Chris Angelico wrote:
> On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk <tundra at tundraware.com> wrote:
>> On 11/15/2013 02:19 AM, Steven D'Aprano wrote:
>>> Nobody sets out to*design*  a tangled mess. What normally happens is that
>>> a tangled mess is the result of*lack of design*.
>>
>> This has been an interesting thread - to me anyway - but this bit
>> above caught my eye.  People write programs for lots of reasons -
>> personal, academic, scientific, and commercial - but I actually
>> don't thing the resultant messes are caused by a "lack of
>> design" most of the time.  In my experience they're caused by only two
>> things:
>>
>> 2) An evolving set of requirements.
>
> This can be an explanation for a lack of design, but it's no less a
> lack. Sometimes, something just grows organically... from a nucleus of
> good design, but undesigned growth. Maybe it's time it got redesigned;
> or maybe redesigning would take too much effort and it's just not
> worth spending that time on something that's going to be phased out by
> the next shiny thing in a couple of years anyway. Doesn't change the
> fact that the current state is not the result of design, but of
> disorganized feature creep. That's not necessarily a terrible thing,
> but Steven's point still stands: such lack of design often results in
> a tangled mess, and a tangled mess can often be blamed on lack of
> design.
>
> ChrisA
>

A fair point.  Perhaps a better way to say this would be "Code that
is a tangled mess is often so because good design was not possible
during its creation."

The problem, of course, is that in almost all circumstances there is usually
not a lot of economic benefit to redesign and restructure the code
once you *do* know the requirements.  Other projects compete for attention
and fixing old, ugly stuff rarely gets much attention.  This is particularly
true insofar as most organizations do a lousy job of tracking what it
is really costing them to operate that kind of code.  If they did, cleaning
things up would become a much bigger priority.

Oh, and inevitably, the person that wrote the code without stable requirements
and without being given time to go back, refactor, cleanup, and restructure the
code ... gets blamed by the people that have to run and maintain it.

<Old Coders Love To Tell Stories Warning>

Years ago I worked for a company that did embedded banking software that
ran on high speed check readers.  It was an "application" that had been
undergoing constant feature creep and change during about an 18 month period
because the woman in marketing running the program get getting
Bright New Ideas (tm) to peddle.

The programmer - frustrated by this - began adding increasingly direct,
personal, and biological comments about said marketing person in the
comments of his assembler code.  Anyway, the new feature requests finally
stopped, and she came in one day to briskly inform us that the code
had been sold to one of our customers and she'd need a tape by end of
week.  The guy who'd been writing all this turned sheet white and scrambled
over the next few days to expunge all his nasty comments from thousands
of lines of assembler.  It was most entertaining to watch ...

-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra at tundraware.com
PGP Key:         http://www.tundraware.com/PGP/