http://www.1729.com/blog/EconomicsOfTestingUglyCode.html

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://www.1729.com/blog/EconomicsOfTestingUglyCode.html
>
> --
> Darren New / San Diego, CA, USA (PST)

That sounds to me like a (very) long-winded way of saying that debugging 'ugly'
code doesn't make it any less ugly--it just makes it run for the time being.

But what strikes me as more interesting is some of his other articles:

"Zero Divided By Zero"
     Ugh, nullity again?

"Music is Things that Happen and Things that Don't Happen"
     Um... and I got a great refund today for the gas I didn't buy...  Isn't
this just a classic jazz quote expanded to the point of ridiculousness?

"Can the Internet Think?"
     "The question of whether computers can think is like the questions of
whether submarines can swim."  - Edsger W. Dijkstra

How I Invented Social Bookmarking
     ...

Could There Exist a Very Large Natural Number Physically Equal to Zero?
From the article: "Of course we know that 1000000 is not physically equal to
zero in our universe, because we don't routinely observe that millions of
objects suddenly disappear. If there is a large natural number N physically
equal to zero, it must be a number much larger than 1000000."
     Oh boy.  And 0.99999... != 1.  On second thought, let's not go there.

 - Ricky

Post a reply to this message

triple_r wrote:
> That sounds to me like a (very) long-winded way of saying that debugging 'ugly'
> code doesn't make it any less ugly--it just makes it run for the time being.

Hmm. I thought it was a fairly interesting (altho not astonishing) 
discussion of value versus code.  Far too many programmers think of 
programming outside the structures of business, capitalism, and so on. 
Not that that's bad, but it's bad if you're trying to be a professional 
programmer.  That's one of the reason Joel's articles are popular, while 
also having a vocal group of detractors - it depends on whether you look 
at programming abstractly or in relationship to your other goals.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Hmm. I thought it was a fairly interesting (altho not astonishing)
> discussion of value versus code.  Far too many programmers think of
> programming outside the structures of business, capitalism, and so on.

Sorry.  Looking back, my comment sounded a lot more dismissive than I meant for
it to.  I just got sidetracked by some things that caught my attention very
quickly.  That's probably because I'm really not a programmer by trade,
although that ends up being most of what I do.  Yes, that's just asking for
trouble.

And this is a constant frustration, since the culture seems to be that it's
better to write and rewrite ugly code that works now than to write extensible
code.  For me, simple 'ugliness' is too one-dimensional.  Add all the comments
and organization you want, but write it in Fortran with modules, and the
reusability shrinks to zero.  Oh, and use whatever language you want because
all we care about is results.  I think this figure-it-out-for-yourself approach
to programming is a real problem for non-comp-sci majors.  It's wasted time for
people who won't need it, but the rest of the time the consequences can be
severe.  Not that I'm innocent either, but I do make an effort.

Assuming you fit into the professional programmer category, are you rewarded for
producing fast, effective results that meet requirements, or for well-written
code?  Not that they're mutually exclusive, but this ugly code has to come from
somewhere, and I can't imagine you're told to fix every mess you come across.  I
can see pressure from above promoting very poor practices that produce short
term gains and long term losses.

As a side note, the 'Refuctoring' link at the top is a good read.  "Job security
index = 1/maintainability."  Cute.

 - Ricky

Post a reply to this message

triple_r wrote:

> I
> can see pressure from above promoting very poor practices that produce short
> term gains and long term losses.

So *this* is how Micro$oft happened? ;-)

BTW, how come this never happens with, say, designing cars?

> "Job security index = 1/maintainability."  Cute.

o_O

My job is doomed...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> 
> BTW, how come this never happens with, say, designing cars?
> 

Actually, it does.

-- 
Eero "Aero" Ahonen
    http://www.zbxt.net
       aer### [at] removethiszbxtnetinvalid

Post a reply to this message

triple_r wrote:
> Assuming you fit into the professional programmer category, are you rewarded for
> producing fast, effective results that meet requirements, or for well-written
> code?

Both.

If I can produce fast results that aren't ugly, I do so. Otherwise, 
generally speaking, I produce fast ugly rather than eventually clean. 
But that's because I work for start-up companies that are much more 
interested in getting customers so they can get money instead of large 
established companies that can afford to take more time.

Were I working for Amazon, for example, I'd expect I'd write prettier 
code. When I'm coding for myself, I write prettier code. When I'm coding 
example code, I write prettier code.

The two problems are these:

(1) You don't always know it's ugly when you write it. You may not 
realize this bit you're creating here and passing to there is going to 
wind up being needed all over the place, so you don't at first make a 
specialized data structure for it. Or you may have the same code in 
three or four places before you realize it really should be a library 
function. In other words, in exploring the requirements and implementing 
them, you learn what parts can be made more meta and hence less ugly. Of 
course, if the requirements are poor, this happens way more often. This 
includes if the program is evolving quickly, such as is common in startups.

(2) Ugliness depends on both program size and complexity and the number 
of people working on the code. If I have a 20-line program to read a CSV 
file, extract three of the columns, and output the SQL required to 
populate the database table it represents, trying to use metaprogramming 
to select those three columns instead of just having three identical 
lines cut-and-pasted with the column name changed is probably more more 
ugly. If I'm the only person working on the code and I'm smart, there 
can be a whole boatload of ugly in there that doesn't interfere with me 
improving it because I can remember it all.

> Not that they're mutually exclusive, but this ugly code has to come from
> somewhere, and I can't imagine you're told to fix every mess you come across.  I
> can see pressure from above promoting very poor practices that produce short
> term gains and long term losses.

Indeed. Generally, I wind up fixing ugly when it gets to be more effort 
to work around the ugly than it does to fix the ugly. I had one 
situation (long, long ago) where the report generation code was so ugly 
I told the boss it would take 2 weeks to rewrite it as a data-driven 
routine and three to move the last column to be the first column.

Sometimes you fix ugly incrementally. The third or fourth time you 
copy-paste a few lines of code, you figure out if it makes sense to turn 
it into a subroutine somewhere. When you have the same routine in 
several programs, you move it from the program-specific library to the 
general library. Etc.

Of course, the best way is to never write the ugly code in the first 
place. With enough experience and je ne sais quoi, you eventually learn 
where the ugly is going to creep in if you don't do it right here. You 
learn that you should (for example) always take the time to create a 
business-object layer[1] and to always use templates[2] for output. 
Other ugliness is harder to catch.


[1] Business-object layer: a layer of code between the raw database rows 
and the application that implements an OO-like layer that talks database 
on the bottom end and application-logic on the top end. Not to be 
confused with DAO or "active records". For example, a set of routines to 
access "the product catalog", even if that's stored in multiple tables 
and has different properties for different objects in the catalog.

[2] Never let the UI people edit your code. Even if it's PHP.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:

> The two problems are these:
> 
> (1) You don't always know it's ugly when you write it.

Hell yeah. Usually I write a program, eventually get it to almost-work, 
and then realise that the way I structured it was totally stupid and 
there's actually a far better way to do the job. Delete, start again. 
Depending on program complexity, it can take a few iterations to get 
this right.

It seems to be that, regardless of which programming language you use, 
figuring out the best way to divide the problem into abstractions is 
absolutely *critical* to writing clean, efficient, maintainable code. 
And it's often not very obvious which way *is* the best until you try to 
actually "do it".

> (2) Ugliness depends on both program size and complexity and the number 
> of people working on the code.

I have no experience of working with other programmers. The only group 
programming project I've ever been involved with was at uni - and I was 
the only person in the group who knew how to program.

Program complexity I can agree with... ;-)

> Indeed. Generally, I wind up fixing ugly when it gets to be more effort 
> to work around the ugly than it does to fix the ugly.

This seems like it's only common sense.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> BTW, how come this never happens with, say, designing cars?

Of course it does.
http://www.ausbcomp.com/~bbott/cars/carhist.htm
At this point, automobile design is more akin to moving from Word 2003 
to Word 2007.

Plus, I guess you never really worked on any of the older cars from the 
60's and 70's? Vacuum hoses to twist the distributor cap around to 
change the spark plug timing based on how hard you pressed the pedal?

I also expect there's a whole lot more ugly inside the design of the car 
than you see from outside. "Gee, I guess we'll have to multiplex the 
signals for the electric windows with the signals for the 'door open' 
warning light on the dash, since if we run *two* wires through the joint 
between door and body, the door won't close easily."

In any case, software is far, far more complex than anything mechanical. 
That's why when things get really complicated, you start adding 
computers to the cars.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
> Hell yeah. Usually I write a program, eventually get it to almost-work, 
> and then realise that the way I structured it was totally stupid and 
> there's actually a far better way to do the job. Delete, start again. 
> Depending on program complexity, it can take a few iterations to get 
> this right.

Exactly. I think I did this about 5 times with LOME before I settled on 
how to implement that. (Including trying it in 3 different languages 
before I realized one with OO and some sort of automated memory 
management would be best.)

> It seems to be that, regardless of which programming language you use, 
> figuring out the best way to divide the problem into abstractions is 
> absolutely *critical* to writing clean, efficient, maintainable code. 
> And it's often not very obvious which way *is* the best until you try to 
> actually "do it".

Yep. That's where the experience comes in. And the natural ability to 
recognise the abstractions in things.

>> Indeed. Generally, I wind up fixing ugly when it gets to be more 
>> effort to work around the ugly than it does to fix the ugly.
> 
> This seems like it's only common sense.

You would be surprised. I've had people do things like pass the number 
of columns wide that the printer report should be in index zero of a 
floating point array indexed by customer age, just so they wouldn't have 
to spend 20 minutes to recompile other parts of the program when they 
changed what variables are shared between programs.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message