How To Work a Sigmoid - Part Two

The last time I wrote about the curvature of project estimations, I was just speculating. Since then, I've discovered that FogBugz does track estimation over time, with a daily estimation record, and offers a graph of the 0, 50, and 100 percent estimates over time. I've been watching this develop for a small time, working more with tracked estimates, and I think some expansion on my thoughts is ready.

You can see my own estimation graph here and it demonstrates exactly what I predicted. I suspect a more complex plotting of points would emerge with the length of the project, but I have a few curiosities about how this would expand over time. The basic prediction of a generally unchanging estimation from the start, an increase in the estimation's growth in the middle, and ending with a calming and final flattening on the systems best guesses, as you slow down how many cases you file for every case that you close.

Steep hills in the estimation happen because for every case you close, you file some bugs, related features, and other cases that were brought to light or just gotten around to filing at that time. You can break down the states of case closure versus creation into three.

When you complete work in line with estimates, then things are On Track. This is misleading, but a good state at any rate. If you have ten hours worth of cases, spend 4 hours, and close about 4 hours worth of estimated cases, the target times on the project remain steady. If you keep this up until all the cases are closed and the project is finished, you can consider your estimations successful. Of course, it is more complicated.

As the design and plans are fleshed out, you'll find developers file more bugs than they close. The estimation is pushed further and further back. This isn't because the project gets more complicated or behind, although it could be so, but that the bulk of the estimation cases needed to represent the entire work of the project hasn't been filed yet. If we could design the entire thing up front, enter the cases, and never change them, we could keep a static estimation, if we remained On Track. We know that we can not and should not design everything up front, so we need to understand and work with changing estimations.

I'm going to make a second prediction about the estimation curve. I predict the curve presents itself in many steps. There are likely to be spurts of case filing and periods of working steadily on those that exist. The developers may have these steps in overlap. Taking some steps back, the steps will smooth into a larger, similar curve for the entire project. Each of these filing spurts will be the start, work, and wrapping up of some component inside the greater breadth of the project.

How To Recognize "Software Development" Is Step One

We're all "making software," but what's that mean? There is no shortage of resources on writing code. Debates rage on about this library and that, emacs versus vi, or nix versus windows versus osx. How much of it matters? We're arguing what car dealership gives us the best deal, automatic versus manual transmissions, and shades of colors to promote the best feelings when you see that shiny new car. Great, you've got the nice car (we all do), now you've got to drive the damn thing and keep it maintained for its lifetime. Who is paying attention here?

We spend thousands of hours discussion how to write software and millions of dollars helping us do it, but most of us have no clue how to keep that code around and get it in the hands of users. I won't make this a post about "The Cloud", but I will say its largely successful, because it solves a problem most developers either ignore or are never properly exposed to.

I won't blame PHP, but it fits to the bill to describe what is either a symptom or a cause of the problem: dump it and forget it deployment, while useful, has made a generation of developers unaware of what may well be the majority of work in their chosen line of profession, if you look at it right. How many people deploy their site by copying some files via FTP, even today? A frighteningly larger number than you might think! How do you think those same individuals debug? Do they even know what the word means?

The problems here stem beyond simply the code slingers, but to the cash slingers as well. Have you ever tried to convince a client that the time spent building deployment, logging, and diagnostics facilities upfront really isn't just a way to bloat your invoices?

I want to take a time out here to admit I'm not really sure where I'm trying to go with this...

Let's have fun and be completely arbitrary in the comments: What percentage of the job do you expect to be writing code when you start and what is the reality?

How To Respond to Google Chrome OS

UPDATE: Fixed 'Response' to 'Respond' in title. Sorry about that.

We all have to do it, so I might as well take my turn.

First impression: no surprise here.

There are expectations in two forms here. We can expect certain things to come of this and we can expect certain things to disappoint us about this. There is a third, external expectation that techies will divide into a camp of people who think its Rilly, Rilly Important and a camp who thinks you're all wasting your time. I mean, gosh, its almost like this is exactly like any other topic we split down some arbitrary middle about. Get over it.

I Expect To Like:

• Cheaper netbooks
• Installing Chrome OS on old hardware

I Expect To Dislike:

• Feeling like I have an OS that won't let me install anything but a browser
• Not being able to install Android Apps
• Not being able to run real Chrome on Android
• Having no way to persist the state of a Javascript VM, so that I can close applications or save memory on long running ones and resume my work later
• Still not being able to sync my bookmarks and open tabs and page states properly (or at all) so that applications that are just websites can easily move from my little netbook to my desktop
• Not getting Android on netbooks, because Chrome OS gets pushed, instead

I Expect To Be Let Down About:

• Getting Chrome OS on Tegra hardware with O3D
• Google doing a funny video in time square asking What is an operating system?
• Never having Google Notebook on a Google Netbook

My lack of pros in these lists that have anything to do with Chrome OS itself are not lost on me. I'm actually excited about it. I think its a really good thing. The availability of this certainly quality project will do great things for our perception of the web, the price points of netbooks, and Christmas in a down economy. The thing is, Chrome OS, at least initially, will be great for what it is not, rather than what it is.

How To Like What You See on the Frontpage

Some suggestions to improve a content voting system sparked some thoughts about the idea and I wanted to write them down to record my thoughts. The initial move was to remove down voting. No one uses it and negatives are, well, negative. So we'll drop "vote down" and replace "vote up" with "like", because what is more friendly than liking something? You know, its like you're in first grade and the article is that cute girl eating paste.

At the same time we were discussing sorting. Everything is chronological, but people might want to see popular things. Is it popular because people vote up on it or because lots of people read it? Of course, lots of places weight these today (like Reddit), so that was discussed.

Third, given the relatively higher traffic we're seeing on video content (duh, Youtube generation), adding a second row of video thumbs to the front page makes sense. I also rolled the idea in my head of adding a little randomness into this section, to get more mileage out of old videos.

Resulting conclusion: we don't care about sorting, we care about clicks (duh, again).

In other words, I shouldn't be looking for how to weight the sort order of videos and stories by popularity, which is the first obvious thing to do. What I need to ask is "which videos, placed in this section on this page, will have the highest chance of being clicked?" The first thought I had going down this road is the two obvious classes of users: new and existing. New users need to get caught, so show them something flashy. Show new users pillar content, a nice video introducing the site, and generally popular things. Existing users, most easily identified by having them log in, have already had the candy and now they want some potatoes. Show them new stuff, things being discussed, and things based on their preferences, if you've got that kind of thing set up.

Another consideration is the predictability of item selection. If I'm going to show eight videos on the front page, why should I pick eight of them? Why don't I pick sixteen and alternate? Not back and forth, but moderately random selections each page load. Really good videos might always be there, and "bottom of the top" videos might show up just now and then. For frequently anonymous users, who think "I'm not sure I like this site enough to sign up yet," get a better range of videos they're exposed to and hopefully more inclined to stick around and sign up.

In the opposite manner, can we figure out what to start excluding? After seeing the same story twenty times and not clicking on it, maybe you stop showing it to them. That space could be used for something they might be interested in.

Of course, I know I'm not inventing everything here, but I wonder if anything is a fresh idea. Obviously plenty of sites are learning to keep popular things around. Is anyone hiding ignored items? I don't know if the things I'm talking about are just "things some people are doing" or if there are real maths behind it and hard terms and concepts I can study to do it right. Hopefully, I'll be able to write more about solid results soon.

How To Own Your Mistakes

Today was a very troubling and frustrating day for both myself and one of my best clients. This is my declaration of ownership for the my own failure to make today not happen. The short story is right after declaring the "make the site more stable" milestone complete and shipping out an invoice, the site spent its most unstable day ever being frantically put on stilts and duct taped to the wall by myself. For the long version, read on.

I had already spent roughly a week and a half working on an impromptu milestone in the project to increase the reliability and stability of the site, as well as beinggreenlit to apply hours to better build, test, and deployment processes. This is a good thing and it still stands as such. Now, the site wasn't fragile before, but a couple incidences understandably gave concern about long term quality. We had a few instances of corrupt MySQL logs, ran out of space on ourEBS volume, and embarrassingly I've had occasion to deploy code and find bugs, even a broken page, even testing locally and trying to be careful. The choice to spend time specifically on a better foundation was a good one.

This isn't about that time I spent, but another post may be.

Thursday we flipped the switch to the new system, running all new instances on EC2, migrated to Postresql, and with a whole new deployment process that includes spawning a new "staging" instance that clones our production web server and lets us test new versions before rolling it out to the public. Everything looked good, I spent some time correcting a couple hiccups, and at the end of the day when things had been running and seemed stable and golden, I declared the milestone complete (and in this arrangement, that means invoicing for a payment, so its not just an ego issue).

I woke up the next morning to find the site had been down for a few hours. It was unavailable about a dozen times throughout the rest of the day, and I clocked about 7.5 hours today getting everything in line. It has been running for longer than that now, without problem, and we seem to be in the clear.

Situations like this require us to look inward and ask what we could have done differently to avoid the escalation of a problem into a crisis, and I've spent much of today, while working on the issues and afterwards, trying to understand this. Much of what I can do now is speculation. While there are many things I could have or should have done, there are few of them that I can know for a certainty would have been "the" things to make a difference.

Priorities are one area I can be confident in believing able to avoid what happened today. A service should not run without thorough watchdogs. Websites should be given realistic traffic test exposures. I can test my code and comment it well, but the upfront work needs to be in place to ensure that my new code is actually servicing requests.

Can you always make these claims?

• Our site's resources are tested automatically and report broken pages and other issues to us
• We can test our production environment before it is actually production for new code
• If something goes wrong, our server processes are restarted and we are informed, before the users know and even if they never know

I know, from now on, I will.