Heroes and Monoliths

I'm sure it's no surprise to anyone, but huge, monolithic software is extremely hard to ship.

It used to be that when I encountered a particularly complex software problem, I would work at mastering the complexity until (by hook or by crook) I figured it out. Then I would proclaim myself victor. It was often the case that people were waiting for me to figure out the hard problem, and would congratulate me on a successful resolution.

However, those congratulations feel empty to me now. I think I can finally appreciate what Dijkstra meant in The Humble Programmer (and here), argument #6:

... the only problems we can really solve in a satisfactory manner are those that finally admit a nicely factored solution. ... By the time that we are sufficiently modest to try factored solutions only, because the other efforts escape our intellectual grip, we shall do our utmost best to avoid all those interfaces impairing our ability to factor the system in a helpful way. And I cannot but expect that this will repeatedly lead to the discovery that an initially untractable problem can be factored after all.

Now I remain unsatisfied until I've solved that problem at hand "in a satisfactory manner", i.e. in a manner that is tractable to read, understand, and change in the future. Not just for me, but for any other competent software developer that comes behind me.

I think this links to the IEEE Code of Ethics, items #5 and #6, in which computing professionals agree:

5. to improve the understanding of technology, its appropriate application, and potential consequences;

6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;

While I was writing this, someone came over and asked me a question about complex software I wrote part of, and I helped him. And I laughed at myself for being unsatisfied about helping him. :)

Vote with your money

There are prediction markets that people have set up. But those feel like a gimmick to me.

I want a place where I can say:

If you can provide a product that meets the following specifications, at the following price, I obligate myself to buy that product at that price.

I want to be able to state conditions like:

• all software in this product conforms to an OSDL-approved license
• the model of car you build has received at least 3/5 rating by Consumer Reports in such-and-such a category
  
• this cell phone comes with a data-only plan
• the out-of-print book that you publish must be hardback
• the eBook reader you create must be able to display scaled PDFs that can be zoomed and panned
  

I want to be able to have a publicly-viewable, prioritized wish list. I want to put things on my wish list that do not yet exist, but that would be very useful to me. I want to be able to say "Me too" to an item on my friend's list and place it on my list at the appropriate priority. And I want to be able to set an annual spending cap, beyond which I am not obligated to purchase anything further.

And I want vendors to be able to query this site for what kind of demand there is for certain kinds of products. And I want vendors to be able to say: "OK, you said you'd buy it, I'm producing it, and if I give it to you in 6 months, you're committed to buy it." The user who posted his/her desired product can specify how much lead time would be acceptable. For instance, I could say: "I don't want you to require any more than 3 months production time for this item."

And it is a binding contract at that point, as long as the item ends up meeting the stated criteria when it is delivered. After the production process starts, a purchaser would be prevented from re-prioritizing or otherwise adjusting his list in such a way that pushes that item below the "obligitory purchase" spending cap line. And if a user defaults on the contract, then the details are publicly visible; likewise for a vendor.

My intent is to have a system that can create REAL demand for useful, not-yet-existing products without having a bunch of focus groups giving stupid requirements to business execs who work up some product that pins its users into a corner in one way or another.

We thank Thee

It is common in my church to pray at the start of church meetings.

At one such meeting, I heard the following in the prayer:

We ask Thee to bless us with all other things that we stand in need of.

and I couldn't help but think how it would sound if someone prayed the following:

We thank Thee for all the things we've fogotten to, or that we didn't think to thank Thee for.

The second kind of prayer would be a more appropriate sentiment.

5 Minute Send

There is something that happens in my mind when (and only when) I push "Send" on an email.

This mental process says "oh, I wonder how it will look when they get this email". So then I go back and look at the email from a completely different perspective -- from the perspective of the recipient. Everybody has a "missed attachment" feature or plugin. But nobody has a "missed idea" feature or a "missed stupidity" feature.

I wish all the email clients I use (gmail, outlook, other webmail) had the following two features:

• "Send" (on a draft message) which means: send in 5 minutes
• "Send All Pending" (on a global menu, not on a message)

Then I could get the benefit of focused authoring *and* self-review when I press "Send" and think "oh, what have I just done".

P.S. I really like blogger's "Post date and time" feature, and I use it all the time.

Nice benefits of git

I use git now and it saved my bacon last week. Two things made a really hard, late-breaking change possible:

1. Ease of integration enabled parallel development.
2. Smallness of commits meant easy bug isolation.

Ease of Integegration => Parallel Development
Because of the ease of integrating small commits, my coding companion and I were able to develop two complementary sets of changes in parallel. This saved us quite a bit of time because we didn't have to wait for each other. The changes were developed as a last-minute response to a problem right before release, and without the ease of integration, it would have been hard to get the problem right on a compressed schedule.

Small Commits => Easy Bug Isolation
Also, because commits are so small (because it's easy to commit without any side-effects, because your repo is isolated from everything else), it was easy to isolate the exact changes that caused a subtle problem. I could have used bisect, but I had an inkling which change caused it, so that was faster. With svn or a mongo patch accrued over multiple changes, it would have been much more confusing and disorienting.

Revert by Commit

Here is a sequence that happens to me regularly:

1. Have a theory about how to fix something
2. Try it out
3. Find out it was a stupid theory
4. Realize that there is a kernel of learning in what you tried
5. Realize that you don't want to throw away that kernel of learning quite yet
6. But want to get the bad changes out of the way
7. But there are some good uncommitted changes you don't want to throw away
8. Ack, what should I do now?

Here is a recipe that makes it really easy to save the bad experiment *and* get it out of the way in ONE step.

• git checkout -b experiment-that-stunk
• git add -i (pick the one or two files that contain the changes you want to get rid of)
• git commit -m "tried to do something stupid, but it didn't work because ..."
• git checkout stuff-i-was-working-on

Revert by commit. Now the changes are gone, saved, explained, pickled for fermentation for more ideas or conversation.

That is something that was NOT part of my experience before git.

Actually, I take that back, I did this once or twice before, but I wasted lots of time because I resisted give up on the experiment at the first sign of stupidity -- I subconciously knew it would be painful to save a whole patch, partially revert, hope I got it right, forget what I was doing, mess it up, revert all the way, re-apply the patch, repeat. So it took longer to abort the bad experiment because of the hesitation because of the perceived expense of partial revert.

UPDATE

I just realized this must be how "git stash" is implemented, and that it's definitely not a new idea.

Software Architecture

This is what I hate about overreaching ideas and projects that accept them:


The whole "coming soon" idea is fine if it lasts for a couple days, but years and years?

Now I'm hanging my head in shame about www.sumsion.org. :)