Blunder Dome Sighting  
privacy 
 
 
 

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.



Click for Blog Feed
Blog Feed

Recent Items
 
VC++ Novice: What's the Visual C++ Express Edition...
 
Code-Monkey Challenge: What is the PSDK Target-Pla...
 
What Is Object-Oriented Design? I have noticed tha...
 
Why Not .rtfx? The Suitability of RTF for Open Int...
 
Recipe for Nano-ISV Success? J. D. Meier just post...
 
The Difference Between Resolution and Size: Or, My...
 
Specialization is for Insects I’ve become a regula...
 
Getting to Unicode: The Least That Could Possibly ...
 
Dear Microsoft: No Thanks for the Updates
 
Raymond Chen: What Feature Did You Remove Today?

This page is powered by Blogger. Isn't yours?
  

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Lair
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome
 
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoCentrale: the Anchor Site
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

2007-06-16

 

Ed Nisley on Software Engineering

Praxis101 has a great post on discrepancies in building an open-source component from the source code, and wondering what to do about it.  Bill had a side note that intrigued me:

[Ed Niseley had an article in Dr Dobbs last year arguing that there can't be a software engineering discipline as long as software developers cannot predict the effects of compiler changes on the resulting code. He has a point. And, no I don't have a pointer to that article.]

I figured that I could chime in by finding the article.  What I found was a gold mine.  You may have to register to follow some of these links.  I can't tell if I have a cookie that is letting me in (and I'm not going to clear mine to find out), but the material appears to be accessible:

  • Dr. Dobb's Portal: Search for Nisley.  No, this is not the first thing I thought of.  But Nisley is a regular and sustained contributor and a local search was the only way to work it.   There are only 95 results (on 2007-06-16), so it should not be too difficult to find what I want.  The problem is looking at Nisley material is like browsing in a wonderful encyclopedia and I have to retrain restrain myself.  I glean some of these in the list below.   
       
  • David Tweed: Circuit Cellar Ink articles by Ed Nisley, #1 (January/February 1988) - #201 (April 2007), bibliography.  Accessed 2007-06-16.  The original Byte Magazine Circuit Cellar projects by Steve Ciarcia were always fascinating, whether or not you ever built any of them.  The Circuit Cellar idea has outlived the magazine and continues.  Ed Nisley has been a regular contributor to that wonderful hobbyist community.
           
  • R. S. Ramaswamy: Articles on Software Engineering Do not Have To Be Dry and Unlettered
    Apparently a typed-in version of Ed Nisley's "Only Stone Endures" from the Developer2 magazine issue of January, 2003.  Anyone who has lived along the route of the Erie Canal will love this piece.
      
  • Ed Nisley: Getting Experienced.  Dr. Dobb's Portal: Embedded Systems, March 13, 2007. 
    "Whether it's avoiding an error you've made before or recovering quickly from a new problem, experience matters."  I need to save this one for VC++ Novice and Cybersmith tips that I am accumulating.
        
  • Ed Nisley: Do the Experiment!  Dr. Dobb's Portal: Embedded Systems, November 1, 2006.
    "Doing the experiments is fundamental to good science. ... Although [the Society for Amateur Scientists] isn't a programmer's organization and the convention had nothing to say about hammering out code, you'll find a link between today's students and tomorrow's tech industry, plus a missing link in the desktop Linux revolution."  Another keeper.  The Amateur Scientist column of Scientific American was a wonderful treat, as were the beautifully drafted beautiful free-hand illustrations back in the 50's and 60's.  This is worth expanding upon specifically for amateur software, with or without any experimentation with devices.  [I need a VC++ Novice post about not being able to directly access devices under Windows too, something Ed has covered.]
       
  • Ed Nisley: Error Checking.  Dr. Dobb's Portal: Embedded Systems, October 5, 2006.
    "Code reviews are just one means of detecting program errors. Ed looks closely at how errors evade detection and gives you the opportunity to play code reviewer."  Oh my, some of the same problems noted in the Ariane 501 analysis are still cropping up.  An interesting addition to for more discussions on the so-called Ariane overflow problem and how we insist on getting the wrong lesson from that. 
         
  • Ed Nisley: Failure Analysis.  Dr. Dobb's Portal: Testing & Debugging, September 5, 2006.
    "Looking back at what went wrong is what failure analysis is all about. And you can bet that government-sponsored programs have lots of experience in this realm."  Another look at some results as well as being obsessive about understanding failure.  This is like reading a techno-thriller of every engineer's nightmares.  More and more for Cybersmiths, along with everything Henry Petroski.  Motivating why this is important and how to get the lessons in all forms of software development is going to be a challenge.
      
  • Ed Nisley: On Engineering.  Dr. Dobb's Portal: Embedded Systems, May 16, 2007.
    "Licensing, quantitative software engineering, and the demise of his antediluvian printer are on Ed's mind."  This column revisits the Professional Engineer question and how software development just doesn't measure up as an engineering discipline at this stage.  I think this might be the article that Bill recalls.  And maybe not.  There's a lot to chew on here.
      
  • Ed Nisley: Crash Handling.  Dr. Dobb's Portal: Embedded Systems, April 7, 2006.
    "Ed tries to track down an error with his GoVideo Rave-MP AMP256 music player. ... Mechanical and civil engineers must consider how their projects can fail, right at the start of the design process."  I think this applies in software development too, for all kinds of software that is embedded in the applications of others.
      
  • Ed Nisley: Tight Code.  Dr. Dobb's Portal: Embedded Systems, March 1, 2006.
    "Ed builds an ISBN bar-code scanner."  Off topic, but classic Circuit Cellar caliber, even though focused on what tight code is all about.  You won't be building this with VC++, that's for sure.
      
  • Ed Nisly: Professionalism.  Dr. Dobb's Portal:  Embedded Systems, January 28, 2006.
    "Ed recently saw no need to renew his status as Professional Engineer."  I find this discouraging and something to understand.  The IEEE Computer Society efforts may be more appropriate.   I just can't tell.  This should make David Parnas unhappy, and that's discouraging too.

There's more but I'm tiring and starting to be careless in my selections.  I'll stop now.

As a bonus, I found this gem, something I have climbed on a soap-box or two about as well:

[update: 2007-06-17T18:49Z found a few off-wordings to repair.  Embellished some of the items.]

 
Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $