> 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, ther

> 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.