I was going to avoid this thread as I knew I wouldn't be able to read it without taking ill but, then for some stupid reason, I dove into it.

OmegaSupreme had me on his side here right up until the comment about hard to design. I have heard that argument from developers over and over and over again and it is frankly rubbish.

"I think we need some better UML style tools so we can get a "birds eye view" ... because is hard to design it correctly up front ...".

Then Straevarus here left me cringing as he brought back memories ...

"We might write our own code, then 1000 lines later, realize that we need to go back and change was we previously wrote"

... memories of 4000 line methods written by "the code guru" at my former employer; methods with a cyclomatic complexity rating well above 70 (when I stopped counting). Methods that contained switch statements nested inside switch statements - something that should NEVER be done as there is no excuse for that kind of cryptic stupidity.

The fact that one realizes 1000 lines later that they need to change something the wrote 1000 lines earlier is 9 times out of 10 (I know, cause I've done it) because they never stopped to figure out what they were building in the first place. Chunks of code separated by that distance should have few if any dependencies that would result in that level of change being needed.

Finally, as I was imagining bungee diving without the bungee, some sanity intruded into the discussion.

"Take a thousand (+ 1) classes on communicating, influencing, and negotiating with customers and managers and your coding will be reduced by 80%, guaranteed". Wstephen

"The point, of course, is that software engineering, after 50 years, still has little in common with real engineering (sorry about your feelings). we insist on doing it different just because we want to." Buggy Fun Bunny

These comments cut to the bone of the problem. The majority of developers seem to refuse to partake in work related communication with others; many sit in their cubicles all day coding and this they consider productive (regardless of how many times they rewrote the same code/classes because they never understood what the code/classes were really supposed to be doing).

For some reason, the software development industry tolerates if not encourages the hacking out of solutions without any thought process. Software is complex; this is true. But so is a bridge from Prince Edward Island to the mainland designed to withstand St. Lawrence River ice floes. So is a Pentium processor. The difference being that with the bridge, the engineers only got one chance to get it right. With the Pentium, they got more chances but magnitudes lower than developers seem to require to produce their "complex" apps.

Rewriting a function to understand it, IMHO, is a clear indicator that either the reader has no patience or the function was abyssmally written in the first place.

Have a nice day.

"As for the concept of software development versus engineering branches, I pretty strongly disagree with the idea that software development is an 'engineering' field. It is more a creative field."

Software development is not art; it never was nor ever should be intended as a creative field. You want to be creative, go into freakin' marketing or sales. With software you are supposed to be building a system that, given a predictable set of inputs, performs a specific task and generates a predictable set of outputs. This is engineering; not art.

My dad was a civil engineer and there was an element of intuition to that job too but the engineer doesn't have their intuitive flash and immediately sneak off into a corner all by their lonesome and dig a hole for a piling or throw up a main support beam. No, an _engineer_ presents the inspiration, epiphany or boneheaded idea to their peers where as a group they consider its merits/demerits and decide if it will be a valuable addition to the plan. The idea is honed to as near perfection as they can take it before they try to realize it.

Many developers (if not most) on the other hand won't present the idea to others because a) they are afraid it is boneheaded and others will criticize their fragile ego - better to have the computer break the news them in private or b) they are afraid somebody will point out that it is a great idea but it really isn't necessary to rewrite that stable piece of code in order to employ the idea or c) "My precious, my precious, don't touch my precious".

Software is art, not because it should be or necessarily must be, it is art because, like those modern artists who throw paint into a jet blast or weld cruddy pieces of metal onto other cruddy pieces of metal, it is built in an ad hoc manner, without any plan, without any direction and without any concern for the future.

An artist will paint a purple background, slap a white oval onto it and run four green stripes across it. It looks like rancid bacon on fried EggBeaters being eaten off of a 90 year old ladies purple sweater but what it really is is a juxtaposition of the emerging environmental movement against the discord of global warming.

TechGuyDave,

My opinion would be that there is no emphasis on reading other people's code in university and college because "that's not fun". The last U course I taught, in January 2006, gave the students the option to build their own code or read and modify a substantial amount of existing code. In general, there were three categories of response:

1) a great deal of whining "there's too much code - how can we understand it", usually espoused after they had destroyed the natural organization of the code by eliminating the directories that housed the code for various components (so they could build it in Visual Studio when I had suggested they use Cygwin and g++ because the build scripts were all done inside the Cygwin environment),

2) a whole lot of "we weren't able to understand it so we wrote our own" coupled with "there was way too much homework assigned"

and finally
3) about 5-10% of the students read, modified and submitted the code that was provided and then sat back and relaxed and watched the others suffer since the workload was quite manageable if you just used Cygwin, the existing build scripts and the existing code.

It was a very interesting exercise in student psychology that, I suspect, is indicative of developer psychology as well. Rather than tackle an area outside their comfort zone (install and learn the Cygwin environment and g++) they decided to stick with what they were comfortable in (Visual Studio) and suffer lots of downstream pain to avoid near term pain.

One economist, writing about the idea of property and the rationale for private property, wrote something to the effect that economic models tend to be based on the "efficient optimizer" model of human behaviour, namely that humans will act in their best interests and will make efficient use of their own resources. He stated that in reality humans are "efficient short-term optimizers". We naturally look for short-term benefit gladly ignoring or deferring pain downstream (i.e., down "time"). We must fight our nature to make a _rational_ decision to suffer the pain early to avoid the pain later. In the software industry, because corporations tolerate if not encourage the hacker, software developers _almost_always_ dive into code (because it is fun - near term benefit) and produce complex, frankensteinian nightmares of code which result in significant long term pain.

Alternatively, if we learned to fight our nature and stop, think and design up front (the pain of having to think hard) in order to make the long term experience "profitable" (in terms of ease and fun "coding, not bug fixing and patching"), we might approach engineering status and build a piece of code that doesn't require 2000 "test runs and crashes" before it is stable.