Software is a static list of instructions, which is constantly changing.

Best Of

[AUTHOR'S NOTE: This is the original contents of a 'best of' post I did long ago, so it's only includes the earlier works. One of these days I'll get around to updating it for posts within the last couple of years ...]

Blogs always see a constant flow of new, possibly intrigued readers.
To answer that all important question that every reader has for a new
blog, I put together a selection of some of my better works. This should
help in making that all important judgment between insane lunatic,
crazy rambler or just run-of-the-mill nut job. It's an easier choice if I
provide references to some of my more interesting pieces, ones that
have a strong point, were more popular or just contain fluid writing.

I've
collected together my favorites with short intros, which I'll update
from time to time to keep it up-to-date. Hopefully I can tag this in
Blogger to make it standout.

If you're a long-time
reader and I missed a favorite or two, please feel free to leave a
comment. If I managed to get a few more suitable entries, I'll update
this document. Comments for older pieces should be left on the original
piece, Blogger will let me know that they are there.

SIMPLIFICATION

Simple
is a constantly misused term. In this post I'm trying very hard to
get clarify the definition of it. It's the sort of thing that programmers
should really really understand, yet the kind of thing that they rarely
do:

Most
of the incoming searches from the web seem to find my abstraction and
encapsulation writings. Again these pieces are focused around clearly
defining these terms. The first entry references the other two, I threw
in the fourth one because its also deals with more essential
definitions:

I've
been struggling for years with trying to find the right words to
explain how to make it easier to develop software. Software development
is a hard task, but people so often make it much much harder than it
actually needs to be. More software fails at the root development level
then it does from organizational problems. If it starts off poorly, it
will fall apart quickly:

Another
interesting post that got a fair amount of feedback. I think that a
simplified high-level (but imprecise) way to specify functionality would
go a long way in reducing risk and allowing programmers to learn from
each other:

Coding
is great, but as programmers we fill up our efforts with a steady
stream of bugs. You haven't really mastered software development until
you've mastered spending the least amount of effort to find the maximum
number of bugs, which is not nearly as easy as it sounds:

I
did a couple of forward-looking posts about things up and coming in the
future. Computer Science forces us to be able to understand knowledge
in a new and more precise way than is necessary for most other
disciplines:

Probably
the most influential thing that I'll write in my career is the basis
for code normalization, however I fully expect that the software
development industry will happily choose to ignore any points in these
works for at least another hundred or hundred and fifty years. Because
of that, don't feel obligated to read any of these, they probably won't
be relevant for quite a while:

This
site is named after my first attempt at a book. I quite work and
decided to push out all of my software development understanding onto
paper. It was something I always wanted to do. I can't say that it is a
good piece of work, but I can say that there is a lot there, it's just
in a very raw form. It was my first big attempt at writing (besides
research papers) and apart from a few typos, the printed edition looks
and feels very much like a real book (my sister says so, and likes the
quotes at the start of each chapter). Professional editing could bring
it out, but I've never been able to convince any publishers that this
'type' of material should see the light of day. My advice, don't buy the
book, convince a publisher to publish it instead (if you'd really like
to read the book, send me an email and I'll send you a copy).

Andy
Hunt suggested a long time ago that my writing was OK, but not entirely
personal. He said I was delivering observations but not tying them back
to the reader. As a sort of fun exercise I set myself the goal of
writing just little thought-lets: two sentence expressions. The first
sentence is completely general, an observation; while the second one
must tie that back to the reader somehow. The earlier versions were on
yahoo360: