Thursday, June 23, 2016

the plan

I asked a person for business advice, and he said - he was kind of annoyed - that I need a business plan, and it had better be good. He suggested I consult a lawyer.

Two months in it was pretty clear that wasn't happening. Besides, if a lawyer was going to talk to me at all it would be because I presented them with a plan. A few nights ago I got really excited, thinking about this, and came up with a list of concerns that need to be addressed in the company manual. It felt pretty complete.

All along these last two weeks I've been making an effort to reprise some of my old experiments, and I got a few pages working that were actually quite fun, but I wasn't satisfied with the code. It was too hard to read, and though it was partially working, it wasn't fully working, and trying to understand the problems it was having was making my brain sort of shut down. I started becoming aware that I needed to take a more structured approach. After applying one set of revisions and discovering that what I was doing was still not actually structured, I could suddenly see that there aren't gradations of less and more structured code ... it's either structured or it isn't ... so I started writing a structured version.

What was the program supposed to do? It was supposed to display images and text in a frame, and then move that frame around. For each of these purposes a system needed to be installed, and I could now see that the function to be called to begin this action was {installcontent;installcontrols}.

It is a function comprised of two function calls, and each of those calls calls, of course, a function, so installcontent = function {getcontentlist;interpretcontentlist}, and so on. Eventually, by working one's way through a series of these rather abstract functions you get to more specific functions like installmotionbutton(motion):{createbutton;appendbutton;stylebutton;addactions}. The functions createbutton, appendbutton, stylebutton, and addactions complete the process of creating that button.

At that point I felt like I had learned what I needed to learn and I dropped the exercise. I'm a little sad about that, but there were annoying technical hurdles on top of the problem of writing the program, and my mind wanted to think about broader topics. For one thing, when developing an algorithm this way the process becomes one of searching for, ultimately, a few short words that describe the whole functioning of the program - or one word, run - and this brief abstract statement is then characterized by similarly compact and abstracted statements describing parts of the "run" process, and, despite being so abstract, these statements can actually be interpreted by the computer. And since my concerns are much larger, as it turns out, than just this page which moves a group of things around - even though they're very much of a piece - it begins to make sense to write highly abstract functions like createacompany{describetheproduct;describeimplementationcycles;assembleaboard;fileforincorporation;deployfirstimplementationcycle}

somewhere in there is the function howbigistech?{search;searchmore;trysomethingelselikehowbigisgoogle?;onlyansweris$500Billionofmarketcap;assumerevenuesof30%ofthat=$200Bils.;multiplyby10}

In short the framework for my business plan is in place, and I feel great about it.