[Cool] My Software Engineering Rant Seven Years Ago

Great Caesar's Ghost! Someone just sent me an email commenting on a usenet post I made seven years ago on software engineering! I actually like what I wrote too, it still seems highly relevant in this day and age. Well, except maybe the part about Enterprise Java Beans... :)

I've edited the line breaks slightly to make it more readable in a web browser.

From: jasonh@xxx.yyy.EDU (Jason Hong)
Newsgroups: comp.software-eng
Subject: [NEWS] Re: Why is programming so hard?
Date: 11 Dec 1998 23:02:30 GMT
...


: 
: I'd like to hear more.  Perhaps it would bring theory, 
: philosophy, and poetry to engineering.

Here's a few I'd also add:

   o No natural visualizations
     There's no simple way to "see" or "draw" software, often 
     making its abstract representation the only one we have. 
     I'm also unconvinced that all of the various object 
     modeling tools and techniques (UML, Fusion, etc) really 
     augment our abilities to think and do design.

   o Scale
     It's difficult to think and design in several orders of 
     magnitude, from bits to gigabytes. Also, the size of state 
     grows exponentially with each new variable. We've had to 
     invent new ways of managing and abstracting this scale, 
     but we still need to do more.

   o Logical thinking
     Let's face it, humans are not innately good at it. Our 
     brains are underpowered for this kind of thinking without 
     lots of training. And logic is the foundation computer 
     systems are built upon.

   o Lack of good tools
     How many people still do debugging via print statements?
     How many people still use editors that have little or no 
        knowledge of the programming language being used?
     How easy is it to profile your application?
     How easy is it to get good visualizations of what's going 
        on in the system?
     Why is using a compiler more like talking to a wall than 
        a dialog between person and machine?
     How many errors are still due to pointer arithmetic and 
        buffer overflows?
     How long does it take to implement a _good_ user interface?
     How many times have teams overwritten each other's code?

     Let's face it, most of our tools are like paleolithic axes: 
     somewhat useful but very crude.

   o Few metrics
     There are few metrics that indicate we as a discipline 
     are improving. Faster processors, cheaper memory, and 
     larger disks only go so far, but what is their relationship 
     to programmer productivity?

     Also, what's good code? How do you measure it?
     What's good design? How do you measure that?

   o Lack of orthogonal properties
     If you want scalability, high availability, fault-tolerance, 
     and security, often you have to build it directly into the 
     software so that it permeates the very essence of the software. 
     
     This mixes the functionality and application logic of 
     the software with the properties of the software, making 
     maintenance, debugging, and testing more complex.

     What we need is a way of separating desired system properties 
     from logic, making it easier to get what you want without 
     having to understand every underlying detail. I do believe 
     Enterprise Java Beans are one small step in this direction.

   o Lack of widespread experience
     People still aren't taught good design skills at universities.
     People still aren't taught good testing skills at universities.
     People still tend to reinvent the wheel because it's too hard
        to find something that fits what you need.
     People still aren't taught good systems engineering skills.
     People are still making many of the same design and 
        implementation mistakes others made decades ago. It's as 
        if we haven't learned.

   o Lack of good methods
     What's the process for creating good software? I really don't 
     believe it's anything methodologies like OMT, Booch, Fusion, 
     and others describe. They're too prescriptive and completely 
     ignore wide areas of real software development.

   o Mercilessly precise need for details
     Computers are stupid, and have to be told every single detail 
     in order to work. Most people don't think in this manner at 
     all, but are forced to adhere to the absolute precision needed 
     by the computer in order to get anything done. 

     This also makes programming real applications more difficult, 
     since people think and do things differently, and your 
     application will have to handle not only the right case but 
     all of the exception cases.

   o Poor understanding
     A lot of people still don't understand that software 
     engineering is more than just programming. It's about 
     prototyping, designing architectures, re-designing 
     architectures, interacting with customers, working within 
     a team, communicating with others, testing the system, and 
     running usability studies, just to state a few.

: But I'm interested to hear some other people's views on why 
: programming is hard by nature.  Or if you don't have time for 
: that, maybe some stimulating articles or books you can refer 
: me to?


Here are a few. Check out:

   o The Mythical Man Month, Fred Brooks 
     (especially "No Silver Bullet")
   o Rapid Development, Steve Maguire
   o Code Complete, Steve McConnell
   o Hints for Computer System Design, Butler Lampson
     http://www.research.microsoft.com/lampson/