programming jokeyjoke

Darren Dirt · December 21, 2011, 03:50:15 PM

A programmer is walking along a beach and finds a lamp. He rubs the lamp and a genie appears. "I am the most powerful genie in the world. I can grant you any wish, but only one wish."

The programmer pulls out a map, points to it and says, "I'd want peace in the Middle East."

The genie responds, "Gee, I don't know. Those people have been fighting for millennia. I can do just about anything, but this is likely beyond my limits."

The programmer then says, "Well, I am a programmer and my programs have lots of users. Please make all my users satisfied with my software and let them ask for sensible changes."

At which point the genie responds, "Um, let me see that map again."

via http://derblub.com/t/joke

Mr. Analog · December 21, 2011, 03:56:56 PM

I've learnt over the years that if everyone is happy with a piece of software chance are it doesn't do much

Darren Dirt · December 21, 2011, 04:02:19 PM

related: http://bexhuff.com/2008/06/why-do-so-many-developers-love-bafflingly-complex-code
(that title totally caught my eye -- and no burns, please, Melbosa...)

more seriously though: "the majority of software failures are communication failures"
http://bexhuff.com/2008/05/empathy-vs-sympathy
http://bexhuff.com/2007/07/top-down-vs-bottom (the debate continues?)

Mr. Analog · December 21, 2011, 04:15:41 PM

I hate bafflingly complex code, in fact I just hit some spaghetti mess this afternoon that made me want to strangle the person who wrote it.

Thorin · December 21, 2011, 06:30:12 PM

I dunno, there's this divide between programmers, I've found, too. Some programmers think simple code is code that has been written into little modules, nice and separated, with not too many lines in any one method or function or subroutine, while other programmers think simple code is code that is all together, even if it is 1,500 lines long and 100 characters wide on average, because that way they don't have to go digging through methods and functions and subroutines.

I'm the former, I prefer any code that is repeated to be wrapped up so it can be called with a simple method call (a well-named one, too, I spend way too much time agonizing over what to name those methods!).

Mr. Analog · December 21, 2011, 07:01:06 PM

I'm wit choo

Tom · December 21, 2011, 07:55:47 PM

Ditto. Sure it can be a bit annoying trying to trace through a relatively complex stack of modules. But a clump of spaghetti code is far worse.

Darren Dirt · December 22, 2011, 02:07:48 AM

Quote from: Tom on December 21, 2011, 07:55:47 PM
Ditto. Sure it can be a bit annoying trying to trace through a relatively complex stack of modules. But a clump of spaghetti code is far worse.

idea: were GnR coders?

Mr. Analog · December 22, 2011, 06:24:20 AM

Most definitely.

Thorin · December 22, 2011, 08:35:17 AM

Quote from: Tom on December 21, 2011, 07:55:47 PM
Ditto. Sure it can be a bit annoying trying to trace through a relatively complex stack of modules. But a clump of spaghetti code is far worse.

The trick is to name the modules properly so it's obvious what they do (or should do), and to make sure they only do their job and anything else. And that's an art. You can spaghetize modularized code just as easily as single-large-function code.

Lazybones · December 22, 2011, 09:45:38 AM

My issue with modularization was always the overhead (extra code / syntax) to pass all the needed data between modules. Most code I was writing would not nessarily be re-used anywhere else in the program, however if it was I would develop an function to handle it for re use.

I know in some heavily modularized apps I tired to maintain, It took for ever to track down code even for the simplest thing since finding the beging of something wasn't always obvious.

Thorin · December 22, 2011, 10:28:03 AM

There are ways to reduce the data being passed and/or make it easier to do.

Having been a maintenance programmer most of my life, I fully understand the frustration of trying to find the entry point to a bug. However, good logging, good exception handling, and proper single responsibility for modules can alleviate that a lot. This is where the art comes in. A properly named module has to do what its name implies, and it must do no more than its name implies. Many developers will throw extra functionality into a module because they don't know where else to put it and don't want to take time to think about where to put it. I blame this on non-technical managers pushing developers to meet an arbitrary deadline.

Mr. Analog · December 22, 2011, 10:37:56 AM

I actually prescribe to many of the tenets of http://cc2e.com/ things like layout, naming, max number of parameters per method etc etc

Personally speaking I think it's a must read (if not a must have). But don't take it from me... http://www.joelonsoftware.com/navLinks/fog0000000262.html

I seriously start to itch when I see more than 7 parameters on a method.

Darren Dirt · December 22, 2011, 02:10:47 PM

Quote from: Darren Dirt on December 21, 2011, 04:02:19 PM
related: http://bexhuff.com/2008/06/why-do-so-many-developers-love-bafflingly-complex-code
(that title totally caught my eye -- and no burns, please, Melbosa...)

Quote from: Thorin on December 22, 2011, 08:35:17 AM
The trick is to name the modules properly so it's obvious what they do (or should do), and to make sure they only do their job and anything else. And that's an art.

Pointing out the "art" aspect, you got me motivated to finally read the entirety of the comments in the article above. Some good food-for-thought, but also there's a link to this excellent list:
http://alexiskold.wordpress.com/2008/04/08/top-10-traits-of-a-rockstar-software-engineer/