Blunder Dome Sighting

Professor von Clueless in the Blunder Dome

status 
 
privacy 
 
about 
contact 

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.

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

Locations of visitors to this page

Recent Items
 
Automated Authentication of Programming Standards?
 
The Important Software Standards: Quality, Performance, and Diligence
 
Virtual Classrooms Model Social/Collaborative Software Direction
 
Microsoft Cracks Open the Word, Excel, and PowerPoint Formats in XML
 
A Litany of Lists: Creatiing Secure Applications
 
As Complex as Necessary and no More.
 
The Same Old Mistakes, Over and Over Again
 
Sorting the Mail: Agile Databases, Vulnerable Applications, and Optimized Code
 
SSH and Known_Hosts Vulnerabilities Threaten Grid
 
Service Research: Focusing on Requirements for Technology, not the Technology

Archives
2004-06-13
2004-06-20
2004-06-27
2004-08-29
2004-09-05
2004-09-12
2004-09-19
2004-10-10
2004-10-24
2004-11-07
2004-11-28
2004-12-05
2004-12-12
2004-12-26
2005-01-30
2005-02-06
2005-03-06
2005-03-13
2005-03-20
2005-04-03
2005-04-10
2005-04-17
2005-04-24
2005-05-01
2005-05-08
2005-05-15
2005-05-29
2005-06-05
2005-06-12
2005-06-19
2005-06-26
2005-07-10
2005-07-17
2005-07-31
2005-08-28
2005-10-09
2005-10-16
2005-10-23
2005-11-13
2005-11-27
2005-12-04
2005-12-18
2006-01-08
2006-02-05
2006-02-12
2006-02-19
2006-03-05
2006-03-12
2006-03-26
2006-04-23
2006-04-30
2006-07-16
2006-07-30

Monday, June 20, 2005

Rigorous Software Engineering at the Application-Domain Integration Level

ACM News Service: Microsoft Research Aims to Ease Development.  Early in my experience with Grace Hopper, I recall a presentation on the introduction of programming languages into IT operations.  She told of the following simple way that she found to overcome the “real programmers don’t Flowmatic” (or Cobol) syndrome:

  • Find some bright kid in computer operations that wants to get into development and turn them loose with the manual and the compiler.
  • As expected, the bright kid (the same ones we recruited whenever they showed up among the maintenance and operations folk) would quickly become quite productive, producing small useful programs that were seen to be needed.
  • The new performer was promoted into a programming position and continued to be rewarded for the high productivity.
  • Other programmers are forbidden to use the new tool.

This came back to me when I noticed that the chosen venue for exploring and proving out the ideas for Rigorous Software Engineering is the new Microsoft Research India center in Bangalore. 

John Ribeiro’s 2005-06-13 ITworld.com article expands on a number of key ideas:

  • There is little or no narration of the work [courtesy of Jon Udell] that is done in software, and that creates difficulties for integrators (among others) who need to dig into the code to arrange for its integration into a larger system.
  • The institutional memory of software designs and architectural decisions need to be preserved some other way.
  • Rigorous Software Engineering is proposed for taking the level of abstraction of the programming closer to the application domain, so this becomes the level of modification and maintenance, using code-generation techniques to move from that level down to lower levels where the software is expressed to the computer.
  • I always wonder how this sort of thing is tested and debugged.  The MSR-India researcher said they intend to create tools that “provide visibility into the system and the way it is functioning at various levels of abstraction.”  That sounds like a valuable way to make sure the higher-level expression has been compiled in a way that preserves essential application behavior.

This is not unlike the Model-Driven Architecture (MDA) view, at a high-altitude of comparison.  I find this appealing, although I wonder whether the rigorous codification of design rules from near-application solution space to platform-specific solution space will be too demanding.  I don’t know. I am curious about that and about how performance factors enter into consideration. 

I do look forward to schemes of this kind for what they show us is involved in near-application modeling as well as reconciliation of problem space and solution space in ways where our clients may be able to check whether we’re building and integrating what they expect.

 

 
Comments: Post a Comment
 
Construction Zone (Hard Hat Area) You are navigating the Blunder Dome

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 06-10-11 15:16 $
$$Revision: 3 $