For my present project, where I'm trying to build the first company worth $1 T:

At my computer I noticed that I didn't have a good way to do something I wanted to do.

Hmm, could there be a project here? Well, I noticed that likely and apparently so far there wasn't a good way to do that and that nearly every user of the Internet in the world might want to use a good solution 1-5 times a week.

So, thought of how I might get a solution:

So, okay, broadly implement the solution as just a Web site.

Next, at the site and elsewhere, collect some good data, use some good, original applied math derivations, and report the results that people would like for the problem.

I investigated what had been done so far, didn't like any of it, and guessed that I might be able to do better.

So, I put my feet up, popped open a cold can of diet soda, reviewed some of my favorite grad school pure math material, took some fairly standard themes in pure and applied math, and did some fast derivations. There I needed to solve some problems from not always having as much data as I would like and some problems in making the data manipulations and calculations nicely fast.

Really, there were those two problems and at least two more. I found what appeared to be good enough math approximation solutions to all four of the problems.

I turned the work, the problem description, the broad ideas for getting the data, the math ideas, etc. into a paper I typed into D. Knuth's math word wacker TeX. There I also typed in the math derivations with the assumptions, definitions, theorems, and proofs.

I reviewed, thought about, and gave a critical review of the material and concluded it looked solid enough.

The math derivations were a solid outline of the crucial core of the software. I also did some work on the design of my SQL database tables, again to make the data handling easy and fast. Then the rest was mostly just for the Web site. So, I learned some HTTP, HTML, CSS, and Windows ASP.NET, designed the Web site and its Web pages, and did the programming for the Web pages. The applied math code is in other programs that communicate with the Web software via object instance de/serialization from/to byte strings and sent via just TCP/IP sockets. That applied math software is single threaded, and the queuing is handled by the TCP/IP FIFO queuing.

There were two big, unexpected problems:

(A) Documentation for what I was using on Windows. So for .NET, SQL server, etc., I found, downloaded, read, abstracted, and indexed 6000+ Web documents. That took a long time.

(B) The motherboard of my development desktop computer got temperature sensitive and gave me some serious boot partition data corruption.

From the beginning through the TeX document, the work went so fast there wasn't much concern about planning.

Once the programming started, the work that was unique to my project was fast, fun, and easy, but unexpected problems (A) and (B) were very costly.

"Fast, fun, and easy"? Yup, since I did the original applied math, programming that was easy for me. For learning HTML, CSS, SQL, etc., that was plenty easy enough.

But a typical problem was a seemingly trivial one -- getting a connection string my Web page code could use to get to SQL Server. Just getting a connection string to work took about a week of throwing stuff against the wall to see if it would stick. I did find a connection string that worked; I still have no idea why that connection string does work but the dozens of others I tried didn't.

At this point the plans are:

(1) Get the development computer back to working again; the main work here is a lot more software installing and configuring.

(2) For some of the crucial applied math code, some of the data indexing is a bit tricky. I've tested that code three times finding no problems, but I want to test it once more.

(3) Then I want to complete a good alpha test.

(4) I'll need to gather and add quite a lot of initial data to my SQL Server data base.

(5) I'll do a semi-public beta test; I intend to ask for beta testers on HN.

(6) Then I'll do the routine things to go live, e.g., tax ID, telling my county about my business,getting a business bank account, etc.

(7) I'll see what the ad networks want me to do to run their ads.

(8) I'll make some efforts at publicity.

(9) I'l go live.

All of (1)-(9) are routine and shouldn't take too long.

Net, the stuff unique to my project was so easy (with my background) that no planning was necessary. For the rest, it was all routine except for unexpected things that I could not have planned for.

But, as software development goes, it's not a really big project: The production code is 24,000 programming language statements in 100,000 lines of typing -- lots of comments in the code. So, with such a small software project, the unexpected problems shouldn't be to serious.

So, the code is short and efficient but, due to the math, should provide the first good, and an excellent, solution to the problem.

So, really, I did do some planning, but due to the unexpected problems the planning didn't do much good!

Maybe the usual lesson is that planning can work well if doing a project one more time where have successfully done a dozen or so earlier versions!

That also holds just for cooking beef stew: The first effort might take too long and yield stew that's not very good! But trial 12 might be fast with terrific results!