Programmer's Toolbox
Some persistent ideas
Jack Crenshaw
12/10/2009 4:07 PM EST
Today, academic disciplines and studies, textbooks, formal methodologies, company training courses, programming guidelines, and peer attitudes may have dampened the wildest excursions of our individualism but not eliminated them.
Like all creative people, software folk often have ideas of their own as to how things should be done. But ideas come in all flavors: some are good, some are brilliant, and some are crushingly, embarrassingly bad. In the end, the trick is not to have only good ideas (that's not possible) and definitely not to blindly follow the ideas of some vaunted authority. The trick, rather, is to be able to discern the good ideas from the bad ones, reject the bad ones, and adopt the good ones as your own.
For reasons I don't fully understand and therefore can't explain, I've often found my own ideas to be out of step with those of my colleagues. These differences led to debates, ranging from polite discussion to out-and-out food fights. In time, I came to accept the battles as part of the profession and contented myself with the observation that "my side" often carried the day.
But I never anticipated that I'd be having to fight the same tedious battles, generation after generation, ad infinitum. Just when I think I've gotten out of the debates, they pull me back in. Just when I think a given issue has been settled for all time, along comes a new generation of programmers, sporting the same tired old idea. Some of the worst ideas seem to enjoy eternal life, enjoying rebirth and returning to plague me, like Count Dracula rising from his coffin.
Today, I'd like to tell you about two of the more persistent and pernicious of the Bad Ideas.
|
|
|
|
|
GerardS
12/17/2009 3:26 AM EST
Hi,
of course - as any sane SW engineer - I agree that not using procedure calls + having every variable global is a very bad idea.
I am not so sure of the past. The key phrase in this article is "I have time". Perhaps NASA has had computers which allowed programmers to have time. But if you have been working in a run-of-the mill university which had two computers with about 1.5 MIPS each for all its theoretical researchers around 1980, saving a few micro-seconds by leaving out procedure calls might have just made the difference between being able to solve a particular problem - chaining jobs and have them run all through the night was a standard measure then - and not being able to tackle it at all...
Sign in to Reply
attila the hun
12/17/2009 9:37 AM EST
Excellent points. I'd like to add that generally programs spend most of their time in a small subset of the code. Spending even a small amount of time with a profiler (or something similar) helps in finding these areas. There's no real advantage in going out of your way to make sections of code that aren't used very often run more efficiently. It's possible to have all of the benefits of modular code AND efficiency, too.
Sign in to Reply
svik
12/20/2009 11:39 AM EST
Moodularity is the most important rule. I agree with you Jack. It is key to get the job done correctly and thus sooner. It also help to make sure all the error cases are covered so there are no suprises later.
However In all the projects I have cleaned up there are always file called something like functions.H, global.h or syswide.h which are always filled every define in the system. Even though there are modules of .C file the system is not modular. The first thing I have to do is split all the .H files and move the defs to their corresponding .H modules matching the .C files. And then to review each module to make sure they consistent, hide local vars, have startup code, etc.
Sign in to Reply
Lunatic Moonshiner
12/27/2009 5:18 AM EST
Jack,
Any thoughts on climate change? Climate changes for sure, but is the devil is in fortran loops?
Sign in to Reply
PWong
1/15/2010 5:43 PM EST
IBM AS/400 has about 40 million objects in 1996. It was never a speed demon but it sure is correct and robust. Heck, you can sit on the keyboards (don't try that on your PC). So banks and lottery corporations use these. Now, if a PhD is trained to use a cannon to shoot a fly, that's what he'll do, because he's too proud.
Sign in to Reply
krwada
1/18/2010 7:09 PM EST
Bowl of Spaghetti is the norm ... unfortunately! I have seen way too many instances of the son-of-BOS.
son-of-BOS == modular coded BOS ...
That is, you use a bunch of subroutines and compact them in a single BOS-type file!
Sign in to Reply
RoweBots1
1/26/2010 9:14 AM EST
Abstract data types and getting the algorithm right first are well known to new graduates today.
Unfortunately the "code first" mentality in many of the "finest" teaching institutions and the lack of software engineering knowledge at the management level persist poor practices.
Sign in to Reply