I've edited the line breaks slightly to make it more readable in a web browser.
From: firstname.lastname@example.org.EDU (Jason Hong)
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.
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
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