Global Sources
EE Times AsiaWebsite
Stay in touch with EE Times Asia
eeBlogs-Article content Home?/?eeBlog?/?eeBlogs
Profile
Nickname:?Bill Schweber???? Articles(77)???? Visits(112261)???? Comments(7)???? Votes(37)???? RSS
Bill Schweber writes about analogue design trends and their impact on the industry, and gives us his expert insight on the role that analogue plays in our largely digital world.
Bill is the editor-in-chief of Planet Analog and a registered professional engineer.
Blog Archive
2016?-? Mar.,?? Feb.??
2015?-? Oct.,?? Sep.,?? Aug.,?? Jul.,?? Apr.,?? Mar.,?? Feb.??
2014?-? Dec.,?? Nov.,?? Oct.,?? Sep.,?? Aug.,?? Apr.,?? Jan.??
View All
Comment?|?Add to Favorites

Posted: 01:47:15 PM, 29/06/2012

Are advanced tools actually counterproductive?

? ?

Recently, I observed 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 redoneall 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 againand 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?


?

Views(1521) Comments(0)
Total [1] users voted ????
[Last update: 01:47:48 PM, 29/06/2012]
Have Your Say!

Bloggers Say

Got something to say? Why not share it with other engineers?

Just introduce yourself to us, we'll contact you and set you up. Yes, it's that simple!

See what engineers like you are posting on our pages.

Interviews & Viewpoints

Talk

Learn how senior executives are seeing the industry from interviews and contributed opinions.

Back
?
Back to Top