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

Darren New wrote:

>> 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.

Experience.

It's like Chess or Go - the rules is simple, but the tactics and 
strategy to play well come only with practice and experience.

>> 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.

GAAAAAH! >_< IT BURNS! IT BURNS ME!! MAKE IT STOP!!!! GAH, I WANT TO 
CLAW OUT MY OWN EYEBALLS!!1!!eleven

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

Post a reply to this message

Orchid XP v8 wrote:
> GAAAAAH! >_< IT BURNS! IT BURNS ME!! MAKE IT STOP!!!! 

The stupid is leaping up off the page and burrowing into my brain!</Dilbert>

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> 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.

Sounds familiar.  The job came down to a lot of signal processing, and I had a
coworker who needed to improve his programming ability, so he decided to write
a Sudoku solver on his own time.  Of course you need to keep track of which
numbers are possible, so in each square for 1-9 a '1' represented a possible
number while a '0' mean that possibility was ruled out.  Why not?  Makes sense.
 But we need to store that data, so lets have '1' correspond to a 1, '10'
correspond to a 2, '100' to 3, and so on up to 10^8.  Just add 'em up.  (so
1100 == 3 and 4 possible.)  Oh, and let's just store that as a real number
since we'll be doing all those log10's anyway.  I was unable to convince him
otherwise, which probably reflects more badly upon me than him, but at least no
one else ever had to see it, and at least I think he used double precision...

 - Ricky

Post a reply to this message

triple_r wrote:
> Sounds familiar.  The job came down to a lot of signal processing, and I had a
> coworker who needed to improve his programming ability, so he decided to write
> a Sudoku solver on his own time.  Of course you need to keep track of which
> numbers are possible, so in each square for 1-9 a '1' represented a possible
> number while a '0' mean that possibility was ruled out.  Why not?  Makes sense.
>  But we need to store that data, so lets have '1' correspond to a 1, '10'
> correspond to a 2, '100' to 3, and so on up to 10^8.  Just add 'em up.  (so
> 1100 == 3 and 4 possible.)  Oh, and let's just store that as a real number
> since we'll be doing all those log10's anyway.  I was unable to convince him
> otherwise, which probably reflects more badly upon me than him, but at least no
> one else ever had to see it, and at least I think he used double precision...

Wait... are you saying that he implemented a bitmap, but in decimal, and 
stored it as a float?

Gah!!!

...Chambers

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:

> Wait... are you saying that he implemented a bitmap, but in decimal, and
> stored it as a float?
>
> Gah!!!

On reading that back, it really wasn't as clear as it was in my head--I should
work on that--but you got it!  Gah is right.  1100 (base 2) => 1100 (base 10)
=> 1100.0.  To get the information back out, you just do a log10, subtract the
largest power of ten, and repeat until you have all the information!  Not to
say I haven't done some dumb things in my day, but *that*...

 - Ricky

Post a reply to this message