Click to See Complete Forum and Search --> : what not to do when programming


YaRness
01-17-2001, 02:18 PM
"ok, i need to make X small change... this shouldn't be too hard.. i don't need to plan or write stuff down..."

GRRR

that's what college was good for though. i'm a lot quicker at hunting down bugs and such than i used to be.

------------------
"Assembly of Japanese bicycle require great peace of mind."
Registered Linux User #188285 http://counter.li.org/

TheLinuxDuck
01-17-2001, 04:39 PM
What I hate is when you have a piece of code working great. Then, you decide to update one small piece of it, and suddenly it doesn't work at all.

I've learned to a. make a copy of the source before editing it, and b. comment out the old stuff, still leaving it in, until the new stuff works. http://www.linuxnewbie.org/ubb/smile.gif

It saves headaches. http://www.linuxnewbie.org/ubb/smile.gif

------------------
TheLinuxDuck
I have a belly button.
:wq

nanode
01-17-2001, 05:02 PM
TLD:

What I hate is when you have a piece of code working great. Then, you decide to update one small piece of it, and suddenly it doesn't work at all.

Something I hate worse than that, is when management asks for that small change that breaks everything.

Topic:
I suppose drinking beer is complimentary behavior to long work weeks. http://www.linuxnewbie.org/ubb/smile.gif

TheLinuxDuck
01-17-2001, 06:00 PM
Originally posted by nanode:
Something I hate worse than that, is when management asks for that small change that breaks everything.

Or, they think it will be a tiny change, it ends up being a huge fiasco.

Topic:
I suppose drinking beer is complimentary behavior to long work weeks. http://www.linuxnewbie.org/ubb/smile.gif

Complimentary? More like a requirement. http://www.linuxnewbie.org/ubb/smile.gif

------------------
TheLinuxDuck
I have a belly button.
:wq

Sterling
01-17-2001, 07:13 PM
Another problem, though, is when there's so much red tape involved with making a change to the plan that you go ahead with the original plan anyway, no matter how poorly suited it may be. One has to strike a balance between the two extremes, which isn't easy. Programming and program design are both very much infant sciences. GUI design even more so. (Don't even get me started on standard GUI design practices! Programmers should not be responsible for that - its the relm of graphic designers)


------------------
-Sterling
"There is no Linuxnewbie.org cabal..."

YaRness
01-17-2001, 07:29 PM
Originally posted by TheLinuxDuck:
What I hate is when you have a piece of code working great. Then, you decide to update one small piece of it, and suddenly it doesn't work at all.

I've learned to a. make a copy of the source before editing it, and b. comment out the old stuff, still leaving it in, until the new stuff works. http://www.linuxnewbie.org/ubb/smile.gif

It saves headaches. http://www.linuxnewbie.org/ubb/smile.gif


i ALWAYS do that. sometimes in a directory i will have script.pl, script.bak, script.bak1, ad nauseum. but sometimes it's not a matter of wanting to make a change, it's more "ok, i got the meat of this working, now time to handle errors/do multiple whatevers/etc.

------------------
"Assembly of Japanese bicycle require great peace of mind."
Registered Linux User #188285 http://counter.li.org/

Mingus
01-18-2001, 01:56 PM
You might want to check out the book by Martin Fowler "Refactoring".

YaRness
01-18-2001, 02:42 PM
another good thing not to do: procrastinate on documentation.

argh.

------------------
"Assembly of Japanese bicycle require great peace of mind."
Registered Linux User #188285 http://counter.li.org/

pointreyes
01-18-2001, 04:14 PM
Had a program working great. Made a little tweak and recompiled the code.

It took eight hours to get the un-compiled and recompiled code to work correctly.

The 400-page documentation (I wrote the blasted thing) on the model includes three pages on how to make two back-up copies before recompiling the code and then test it before moving it over to production.

nanode
01-19-2001, 07:19 PM
Get this - I had to write the spec. and requirements for my project. I don't mind writing the docs - but they expected me to know what THEY wanted. A competitor had a product written in VB, and my task was to reverse engineer and code mine in Java. Problem is, when you reverse engineer something (I've learned now) your spec. is a moving target as you discover new elements of the design. ("oh gee, I'm gonna need to write a so-and-so...")

<rant> converting MFC GUI properties to JFC GUI properties absolutely sucks $#@!. Everytime someone tickles a display widget, it needs to broadcast it's properties in both MFC terms and Java.

Each end of the big product is now in Java, but because one end (mine) previously was MFC, both ends translate to MFC in the middle and go back to Java style on either end.

It feels like that Polish joke when the dude stands on a ladder holding a light bulb, and the other guy's job is turn the ladder around until the light bulb is unthreaded.
</rant>

BTW: I think it's my job to turn the ladder http://www.linuxnewbie.org/ubb/smile.gif