Redefining Programming Close to the Metal

In a previous life I was an embedded systems programmer, there was nothing like defining the hardware, getting the boards made up, and creating the equivalent of the "Hello World" program to make sure hardware can come to life, something as simple as a flashing LED or toggling a pin and checking via an oscilloscope. I used a language called FORTH which I still have a soft spot for. Although probably unreasonable, I think everyone should go through this process; “programming close to the metal”; it give a completely different perspective on writing code (I ?think? a good one).

Flash forward about 13 years and I find myself doing web systems, this is not at all a bad thing. We’ve recently went live with a site www.uspaymail.com and again my perspective is changing, perhaps it’s the problem domain in this case. We have built the system on a solid set a of services both UI and data layer that I’ve been evolving over the past 7 years. Therefore adding new features is relatively straight forward. This application has also a very solid and predictable revenue model, basically if we sign up users and we sign up advertisers, our revenue is predictable. At this point our mission statement to grow our application and thus income model is to sign up users (and keep them coming back) and advertisers, anything else is secondary, and thus the concept of “programming close to the metal” isn’t going to be referred to as making the microprocessor dance, but providing an experience for both the user and the advertiser as pleasant and rewarding as possible. How do we do this or more importantly how do we know how we are succeeding? First we define our currency or what metrics are important to succeeding in our goal. These seem straight forward, but these metrics should be visible to everyone on the team.

· Total number of subscribers – How many users are currently signed up

· Total number of new subscribers per day – On each day how many new people signed up

· Percentage of users on each day that access the site – Total number of unique users that access the site on each day over the total number of subscribers, currently we have a target of 33% but that metric still needs a little more definition.

What we did for our app in our administrative console, we have a marketing section (possibly incorrectly named) that has the following charts that are live:

Total Site Subscribers

New Subscribers Per Day

Returning Users
The current day is live so the number grows through out the day)

As the techie responsible for this site, I also have a considerable number of metrics on the backend that measure application performance. Basically these measure the time between ASP.NET page life cycle events such as Pre-Init to Init. I’ve also instrumented our layer on top of the database to measure the time each query takes, if a query takes more than 10ms, I log that. This will be key to keep our application snappy.

So now that we have our metrics, it’s very helpful in prioritizing work. Our system at this point is 100% functional so feature can be prioritized based upon the impact they have on improving our defined metrics. Since we have these metrics very visible, it’s easy to see if we are moving closer to the mark or we are just spending developed dollars on non-value add items. And thus we are working close to the metal even though there are many layers of abstraction between our application and the processor.

As this progresses, and as I learn more about what works and what doesn’t I’ll continue to post my findings.

-ec