> Although I'd say developing software is seldom truly low risk, most people just don't understand how difficult this can be (it's a people problem).

Yes, there's a long history of too long delayed or
failed software projects.

One way and another, mostly
I've managed to avoid such
projects. My experience has been that
software projects are fast, fun, easy, routine,
and low risk.

But, currently I have encountered
an exception: My current project involves
my bringing up a Web site, and, for whatever the
balance of reasons were, I decided to build
on Windows. I'm writing in Visual Basic .NET --
apparently essentially equivalent to C#
but with a different flavor of syntactic sugar
that I like better than the deliberately
idiosyncratic syntax of C borrowed by C#.

The Visual Basic .NET has been fine -- really
nice. And how it works in developing Web pages
is even nicer. And I just keep typing into
my favorite text editor, where I have
100+ macros and can easily write more,
and don't try to
make use of Visual Studio.

But the problems are: (1) Documentation of the
many classes I needed to use
in the .NET Framework, ASP.NET (for the
Web pages), and ADO.NET (for using SQL Server),
(2) software installation, (3) more in
system administration, and (4)
system security.

The part of the software development
uniquely mine has remained fast, fun,
easy, routine, and low risk.

E.g., once it was a week of mud wrestling
just to get a connection string that worked
between one of my Web pages in Visual Basic
and SQL Server. The documentation was clear
as mud, and I just had to throw guesses
out until one stuck.

A virus wiped
out essentially all of
my installation,
and I had to reinstall
the OS and all the software
starting again with an empty boot
partition.

Then the reinstall of SQL Server
messed up, and I had to start again,
with an empty boot partition.

Then I tried to get SQL Server to use
my old database, and SQL Server got sick;
I tried to reinstall SQL Server, and
Windows got sick, and I had to reinstall
everything to an empty boot partition
again.

I decided to
back up the boot partition using
NTBACKUP, and when I needed the back up copy, the
restored copy didn't boot.
So, right, I had to reinstall everything
to an empty boot partition, again.
This was getting old.

Why did the restore not boot?
Secret #119,385,232,345: When back up
a boot partition
with NTBACKUP and want the result,
if restored, bootable, then
have to request
"do save system state". What the heck
was system state, my options
for Outlook? Of course, the documentation
never said, never gave any discussion,
etc. So, all there was was a
check box. Thanks a lot, guys.
Nope, "system state" is much more
important than my options for Outlook,
as I eventually
discovered largely by accident
from looking at the log files
from a save of my boot partition
with WinZip.

So, to be able to use NTBACKUP,
which actually has some amazing
functionality if can get it to work,
I ran experiments, installed Windows,
backed up with NTBACKUP, tried a
restore, which failed,
tried again, and kept up this work
for days before I got it all working
well. Then I documented it, the whole
thing, click by click, keystroke by
keystroke. Now if my boot drive
gets sick for any reason, I can boot
Windows from another bootable
partition and restore my main
partition. And I can back up my
bootable partition with NTBACKUP
easily, routinely, in less than
an hour, any day at lunch.

I found, downloaded,
read, studied, saved, indexed,
and abstracted 5000+ Web pages of
documentation, nearly all from MSDN.
That was a lot of work.
Plus more work for documentation of
SQL Server.

For SQL Server, even for
some basic, simple things, I couldn't
make sense out of the Microsoft
documentation. And for their
SQL Server Management Studio,
eventually I saw how to use it
usefully
for just browsing but never
saw how to use it for
actual SQL Server management --
it's awash in check boxes,
panels, and windows I have no
idea what the heck they do if
anything or anything useful.
So for
management of SQL Server,
I used just
standard, vanilla SQL commands
as documented by other than
Microsoft. So, eventually I
was able to get by
the issues of users, logins, passwords,
the SQL Server versions of
capabilities and access control lists,
databases, etc.

For using TCP/IP on Windows,
I could make no sense out of
most of the Microsoft documentation
so just returned to some
old documentation of TCP/IP
and some old sample code of mine,
saw again what the basic
API functions were,
guessed what Microsoft had
as the equivalent, and got
some TCP/IP working between
some servers.

It went on this way: Documentation,
installation, management, and security --
mud wrestling. It cost me years,
a big chunk of my life, a WMD to my
finances,
where all the while the part of the
software uniquely mine was
fast, fun, easy, routine, low risk.

But apparently now I'm past much of
that mud wrestling with documentation.

Security? Just spent the past six
weeks (outrageous) getting rid of
a virus I picked up from somewhere,
maybe Flash (they keep saying that
their software is a security risk).
The Microsoft virus scanning tools,
which I ran for days, didn't
fix the virus. Eventually a
System Restore back to two months
earlier did.

What other people do about these
issues I don't know.

My part? Fast, fun, easy,
routine, low risk.

My Web site architecture has
several back end software servers
communicating via TCP/IP.
The architecture is all nicely
scalable just via simple
sharding. E.g., I wrote my
own Web site session state server,
just as a key-value store,
using just TCP/IP sockets,
class instance de/serialization,
and two collection classes.
Fast, fun, easy, and the code
is blindingly fast -- from my timings
a server costing less than
$1000 in parts should be able to
do the session state put and get
work for sending 5000+ Web pages
a second, and simple sharding
could increase that by a factor of 100.
Easy. Fun.

Some of my servers are doing, say,
an exploitation of the Hahn-Banach
theorem in a Hilbert space. Not trivial.

And, yes, have to expect that at some
point will need some numerical linear
algebra. So, I downloaded the Fortran
version of LINPACK, used the utility
f2c (translate Fortran to C),
compiled the C code, tested it,
worked fine, and used Microsoft's
platform invoke to call the C
code. Did lots of testing and timing --
it works fine.

I needed a couple of fast, cute algorithms,
invented them, programmed, tested, timed,
and documented them -- they work fine.

For my SQL Server schema
(that is, the tables, columns,
and other properties, that is,
not what Microsoft's SQL Server
Management Studio calls
a schema), SQL was fast, fun,
and easy. Heck, long ago
in a few days eating dinner at the
Mount Kisco Diner while reading
Ullman's book on database and SQL, I got it
on the language, right away.
So, for my project, in about two
hours, fun, easy, I wrote out, with soft pencil,
my schema for what my project needs
now and for much more in the future,
typed in the schema, and it's
been fine ever since. I have
enough keys, etc. to make
everything really fast without any
joins. Simple. Fun. Right,
so far I should be able to
get by with just a key-value
store, but RDBMS still has some
advantages if I can get through
the documentation actually to make
the advantages work. Here I
anticipate a lot of mud wrestling
and/or some really good technical
support.

Looks like I will have to set up a
computer on the side and use it just
to practice installs, backup, restores,
etc., over and over and over,
finally document what
actually works. Then use
system management automation means
to automate that work.

There's an old statement about
some of IBM's software:
"If you just follow the documentation
for how to do the installs, then
I will guarantee you it won't work."

SQL Server installation, documentation,
and administration -- barbed wire enema.

My part's easy.

For working through Microsoft's part,
maybe I'm past that.