Bad habbits in computer programming

[K.I.L.E.R]

I have this REALLY horrible habbit.
Actually it's more of a mentality I developed over time.

If I know of a way to solve a specific problem in a very small amount of time I avoid it at all costs.
I have a very bad fear of performance loss, regardless of programming language.

If I can solve a problem in 3 lines of code and if I deem it inefficient, I find something more complex and implement that and I spend about 30 minutes looking for faster alternatives and benchmarking each and every one of them in different situations.

Anyone else have this problem?
It really does kill productivity.

 

[Simon F]

I have this REALLY horrible habbit.

What? Besides bad spelling?

Actually it's more of a mentality I developed over time.

If I know of a way to solve a specific problem in a very small amount of time I avoid it at all costs.
I have a very bad fear of performance loss, regardless of programming language.

If I can solve a problem in 3 lines of code and if I deem it inefficient, I find something more complex and implement that and I spend about 30 minutes looking for faster alternatives and benchmarking each and every one of them in different situations.

That's a serious problem. Can I suggest you wire up your programming chair to a high voltage source and a timer? That should teach you the desire to get things done sooner.

 

[Crisidelm]

Bad hobbits pal, bad hobbits

 

[Powderkeg]

I have this REALLY horrible habbit.
Actually it's more of a mentality I developed over time.

If I know of a way to solve a specific problem in a very small amount of time I avoid it at all costs.
I have a very bad fear of performance loss, regardless of programming language.

If I can solve a problem in 3 lines of code and if I deem it inefficient, I find something more complex and implement that and I spend about 30 minutes looking for faster alternatives and benchmarking each and every one of them in different situations.

Anyone else have this problem?
It really does kill productivity.

All that matters is how you are getting paid. If you've got a "normal" 9-5 job (Yeah, it doesn't happen in programming, but...) then it really shouldn't matter to you. If making things the absolute most efficient is important to your job, spend as much time as you need on it.

However, if you are doing contract work, this habit will cost you money. You'll find yourself frequently underbid by someone else who can get the job done in half the time, and the difference in the end result would likely not be noticed by the customer.

 

[London Geezer]

You have hobbits in your PC?! And they're BAD hobbits?!!!

 

[K.I.L.E.R]

Sorry I meant habit.

I don't do this when I have deadlines though.
I've done my assignments in like 1 hour without even bothering to optimise them, as long as they work.

 

[Powderkeg]

If you've got time to waste, wasting it being productive is a good thing.






Something I should be doing, perhaps....

 

[Karoshi]

Bad rabbits in computer programming

Premature optimization is the root of all evil (STR). Usually there is no point, you'll be making 0.003% of the runtime time run in 0.002% of the time, you slashed relative runtime time by 33% woot! but your program will run 0.001% faster (whatever, dont check my % maths). I've seen this happen in some projects, and it was just an unnecessary pain (that made debugging impossible: clone(2) is not meant to be used directly, at least if you want to use gdb and mantain your sanity).

So yeah, you have a bad programming rabbit. Profile on real usage to see where you should optimize. You'll get to the point of diminishing returns really quick.

 

[Nite_Hawk]

Premature optimization is the root of all evil (STR). Usually there is no point, you'll be making 0.003% of the runtime time run in 0.002% of the time, you slashed relative runtime time by 33% woot! but your program will run 0.001% faster (whatever, dont check my % maths). I've seen this happen in some projects, and it was just an unnecessary pain (that made debugging impossible: clone(2) is not meant to be used directly, at least if you want to use gdb and mantain your sanity).

So yeah, you have a bad programming rabbit. Profile on real usage to see where you should optimize. You'll get to the point of diminishing returns really quick.

I'd only agree with this from the standpoint of doing things like loop unrolling, cache behavior analysis, etc. On the other hand I think it is extremely important to factor in performance concerns when you are in the design phase and react accordingly. Is the target system likely to have low memory? Pick your aglorithms with a bias toward low memory complexity. Are you expecting to be limited to by network bandwidth? Think about using a binary transport rather than soap. Running your software on a slow embedded processor? Make sure you aren't depending on complex compression schemes to get around slow network connections.

It's one thing to avoid needless complexity early in the project, but it is another thing to entirely ignore performance concerns and end up writing something that while pretty, is enitrely unsuitible for the target platform.

K.I.L.E.R:

What I would suggest doing is before you write any code, think about performance abstractly like you might form ideas for your public interfaces. Are you likely going to be IO bound? If so, how might this affect the overall design of your software? Instead of micro-optimizing each for loop you run into, think about what kinds of tasks your application will be spending time doing, and factor that in when you create your design. It's not a sin to think about performance when designing a project. Just don't needlessly optimize code that isn't causing a bottleneck.

Nite_Hawk

 

[Ali]

I do the same kind of thing. My 'first-run' is normally the first solution that comes to mind. I get that running, and benchmark it.

While doing the first run, I normaly come up with ideas of how I 'should' have done it, and if I have time I implement those and benchmark. I sometimes end up with 3 or 4 different implementaions.

Once they are all benchmarked, I pick the fastest, and test it to destruction, and if it works, plonk it on the version tree. If it doesnt work, and Im low on time, I test the next fastest, etc.

Of course, code readability, realiability, elegance all come into play. If I come up with a method thats just ugly, even if it works I turf it out.

Of course, I work in the Financial markets, and have a lot of time to do pretty simple things. For example, yesterday I did a simple historical data analysis routine. First method took 8 minutes to sample 300 odd securities. Final method took 26 seconds. It will only be run once a month or so, but I had nothing else to do, and could spend a full day on it. None of the traders seemed to care that the old system took about an hour to run though (very badly written).

Ali