Weird and Wacky Engineering
Can advanced tools actually slow us down?
Bill Schweber
5/23/2012 1:29 PM EDT
I recently watched someone typing a lengthy analysis in response to an email. What a sight it was: fingers blazing, keys clicking, and that poor "delete/backspace" key getting an Olympic-class workout. And no, it was not just a case of poor typing skills.
It was a case of typing and untyping over and over, like being stuck in a "do…while" loop without any exit. Each word, phrase, sentence, and even paragraph was done and redone and redone—all at high speed, of course, which word processing makes so easy. I estimate that the ratio of entered keystrokes to final ones actually used was about 10:1.
Some thinking begins
Then I wondered, what would it have been like to do that by hand, or even with that now-obsolete instrument, the typewriter?
Of course, if you were doing this by hand or with a typewriter, you wouldn’t have the "luxury" of such ease of do, delete, and re-do. Now, it's so easy to jump in and get going, and keep going, that there's little need to stop first and think, or so it seems. After all, you can correct, edit, re-do, and re-arrange almost ad infinitum, if not ad nauseum. It's as if the movie Groundhog Day met the cliché from those old movies about newspaper reporters, where the grizzly veteran editor yells "get me rewrite."
The effect doesn't apply just to writing, either. I like to watch a TV show called The Woodwright's Shop, where the host uses only hand tools from about 1850 or earlier, mostly planes, saws, chisels, scrapers, and dividers (but no sandpaper). What always impresses me, besides his sheer skills and apparent ease while doing a project in a 25-minute block straight through, is how much thought he puts into each step before he does it. Mistakes are fairly rare.
When you think about this, it makes sense. If you ruin a piece of standard lumber these days, you just run over to the nearby building-supply store and get another, no big deal. But "back in the day", a ruined piece was a major problem, as replacement material had to be sawn, planed, squared and trued, all of which took a lot of time and raw effort. Much better to get it right the first time, if at all possible. (The same consideration applies to writing with quill pens and costly paper or parchment, as all were very precious; you likely even had to make your own ink.)
The engineering aspect
It's not just personal projects which now have this "do it fast, and do it over (and over)" mode. The relative ease with which we can now write code, then execute it, test it, edit it, and re-execute it can discourage proper planning, despite all the formal coding procedures which software engineers claim they follow.
The excellent book Digital Apollo details how the code which the programmers of the moon project created was actually transformed into executable instructions for the processor. I mean this literally: the 1s and 0s of the coded instructions were set by hand into core memory strings, a process which took weeks for each revision. If there was a bug or problem, then the entire lengthy process had to begin again. You can be sure that these programmers didn’t just bang out their software; they analyzed it long and hard first, since the debug and edit process was so painful.
Today's pressures don't allow for much of the "first, stop and think" or even "first, slow it down" approach. Plus, the tools we have encourage the "do it fast, then fix" approach. It takes real discipline to not be driven by the pressure from management, especially when it aided by the programming tools which are literally at our fingertips.
Too much of a good thing?
Maybe this pace is actually counterproductive, and we should remember that sometimes it's better to go slow and careful, than go fast but have to do it over and over again—and the appearance of non-stop activity on a project is not the same as actual progress.
Have you seen instances where going slower and steadier would have been better and actually resulted in a project finished sooner? ◊
|
|
|
|
|
cdhmanning
5/23/2012 10:39 PM EDT
I remember my first year of programming. FORTRAN on punch cards using a mainframe. We submitted our programs as batch jobs and got a print out back hours later.
Due to the time involved, you would be very careful about what you submitted, painstakingly checking the code before cutting cards (cards == money) and then checking the cards again before submitting.
It was more than once that a 200-line program ran - correctly - first time.
Frugality was important too. I wrote a 56-line Fortran program to print out wall calendars. Worked great, but was pretty hard to understand.
Now editing and compilation is cheap/free and I don't worry so much about getting it perfect first time.
Forgot a variable name? So what just compile and see the errors the compiler throws up.
Would I trade back for the Good Old Days? No thank you! I also remember dropping the 2000 punch-card source code for a compiler when I tripped down some stairs. It took quite a while to get them back in order and re-punch damaged cards.
Sign in to Reply
Les_Slater
5/24/2012 5:21 PM EDT
Remember back in those days drawing diagonal line on the edge of a deck of cards so if they were dropped all you had to do was carefully get that diagonal line back.
Sign in to Reply
Duane Benson
5/24/2012 11:54 AM EDT
It's not just the "do it fast/do it over" that causes me to sometimes question all of the "advances." The proliferation of options is also staggering. If you look at all of the library functions available in .NET and other tool chains, you can spend a lot of time just searching to the right library function to use. On the one hand, that frees up a lot of time from wrote tasks, but it also can cause delays. There are so many that you can't keep them in your head so you likely have to research each time you need to use one.
Sign in to Reply
DickH
5/26/2012 9:38 PM EDT
that's what a lot of folks say about C++ - you get 'choice/decision paralysis' because there are to many ways to code something - and it's not at all obvious which will be best. A great language would point obviously towards the best approach
Sign in to Reply
Duane Benson
6/5/2012 12:21 PM EDT
It almost seems like even the people at Microsoft designing the Windows libraries forget that some task already has a library function written and just write a new one. Or maybe, it's just easier to create a new one than update an old one and go through all of the compatibility testing that would be required.
Sign in to Reply
WireMan
5/25/2012 3:34 PM EDT
New tools would probably be great if only the documentation kept pace. While trying a new software IDE for a microcontroller a few days ago, I inadvertently closed two windows on the display. I couldn't figure out how to get them back. The docs explained what those windows would show but had no information about how to open them. Sad.
Sign in to Reply
Rod Dalitz
5/25/2012 4:46 PM EDT
I have a motto over my desk: "Why is there never enough time to do a job right, but always enough to do it over?"
Sign in to Reply
MarvA
10/10/2012 8:34 PM EDT
Don't I know it? A lot of the work that I do is troubleshooting serious design problems in different systems. It has to be right because of the usual critical nature of the issues.
My real projects get delayed but no one pushes me.
I got to be the slowest designer in the company but stuff works when I'm done.
Sign in to Reply
psw_#1
5/25/2012 5:15 PM EDT
The long-short way to the door, versus the short-long way... Event driven and schedule aware, not schedule driven... Plan the plan, execute the plan...
Sign in to Reply
seaEE
5/26/2012 10:15 PM EDT
The person sitting in front of their computer appearing to be doing nothing may actually be thinking about how to solve a problem or how to best organize a process. On the other hand, the person frantically hacking away at their keyboard may be making a host of mistakes and bad, quick decisions that will affect a product for a long time down the road.
Sign in to Reply
sudo
5/28/2012 4:51 AM EDT
Bill, are you describing SCRUM design methodology? Oh, that's Schwaber, not Schweber! ;-)
Good point and this is not just a time issue, either.
I admit, I sometimes embrace the dark side and I just tweak and throw the code at the FPGA compiler, again. This only works though if the basic architecture is sound and it's a double-edged sword if this is meant to save time. What if there is another error behind the error? And one behind that? Time to stop and think!
If I jump in without proper thinking upfront and hope to do the checks later, the architecture will resemble the proverbial dog's breakfast and when finally the design appears to work, then the obvious temptation is not to look too hard for possible errors still hiding, especially with increasing time pressures on the project. It's just human nature.
Sign in to Reply
Les_Slater
5/30/2012 11:24 AM EDT
We need a formality in which a problem or task is completely defined and the tools that go from that definition to the executable.
Sign in to Reply
masher
6/4/2012 1:09 PM EDT
I had a junior engineer wait a month until he had the latest and greatest RF design software before he would even attempt a prototype design of a new power am design.
He wanted to do a harmonic balance along with several other competing analysis before he would even attemp a bench prototype.
The only software we had was an older RF package that was simple, easy to use and plain worked, albeit with a bit of bench tweaking to fine tune the circuit but it never let us down.
It was the minimal tweaking on the bench that this new grad wanted to eliminate and bench tweaking was out of the question, His thought was push a button and have a working design come out the other end without any knowledge of what could go wrong which you only obtain from actaul bench experience.
Unfortunately when you spend 60 thousand dollars to replace your existing EDA software and the new software requires a couple of months to learn how to use, you also loose valuable time in which competitors get their product to market.
You can train a pilot to take off and land in a simulator but you sure as heck are not going to give him or her a pilots license to fly a commercial airliner until they take the seat of something simple and basic to start out on.
Sign in to Reply
seaEE
10/11/2012 12:08 AM EDT
"Measure twice, cut once." The problem is, if you measure twice, people think you are wasting time.
Sign in to Reply
Fabio007
11/21/2012 4:43 AM EST
"More haste, less speed."
"Months of coding can save hours of planning.".
Yes, I have seen contract programmers display both of the above. They write code, do some testing, get paid, then move on. Management pats itself on the back thinking the jobs done.
Only later when a new software feature has to be added that the true nature of the beast is revealed. Suddenly it becomes clear that coding and documentation standards were not followed. Management was too hasty in accepting the "product", or the person allocated the task of checking "product compliance" was not up to the task, or was put under extreme pressure not to hold the project up. The software contract has no clause for redress. The original coder is no where to be found.
But that is months down the track, and becomes somebody else's problem... usually mine.
Sign in to Reply