Programming Analytics

He passed away today.  Here’s a great interview from his earlier days.

This guy was hard.  He was a tough bastard, and you’ll appreciate how his completely indomitable attitude created the modern PC market, both created and destroyed the Atari videogame bubble in the early ’80s, and led to Bill Gates’ domination of the PC industry for the next twenty years.  The book is Brian Bagnall’s Commodore: A Company on the Edge; an extremely intimate view into what led Chuck Peddle to redefine computers with the 6502 and how Jack Tramiel capitalized on it.

He also won an incredible deal out of Bill Gates when he licensed Microsoft Basic for the Commodore PET and all future Commodore products.  I bet Bill Gates is still smarting over that one.

It may be obvious how Jack created the modern videogame industry - by providing an inexpensive microprocessor, he created the opportunity for the Atari 2600 to exist.  But then, immediately afterwards, he created the Commodore 64, a platform so good and so vulnerable that everyone copied games for it - and the games industry became an immense hobbyist playground.  Nobody paid for crummy Atari games anymore when Commodore games could be shared freely; and eventually the modern console industry was born.  It ran on a 6502.

Of course, the good times can’t last forever.  Steve Jobs pulled a Tramiel by replacing virtually all expensive console games with $0.99 iTunes products; we’re all living with that now.  Fortunately, this time around, high quality AAA-level products will continue to exist for us all to enjoy.

This article at the ACM explains Stanford’s CPUDB project, which analyzes historical and modern SPEC performance numbers using a clever batch of extrapolation and metadata.  It’s clearly the definitive database on CPU history and a treasure of resources for geeks like me who can’t stand to switch back to CPU95 for historical reports.

http://queue.acm.org/detail.cfm?id=2181798

The actual CPUDB site is still too overloaded; but I have no doubt it will be visible soon.

http://cpudb.stanford.edu/

It’s worth mentioning that processor success is both traceable to improvements in architecture and process; although it’s interesting to notice that architecture improvements also cover efficiency improvements that allow the chip as a whole to run cooler.

As many of you know, the x86 instruction set was pretty wacky.  It accumulated lots of interesting ideas over the years, most of which gradually got superceded and replaced by better ideas.  But, for legacy reasons, many of them had to stick around.

One of the most unique problems with calling conventions has apparently been addressed - it’s just been so long since I did assembly that I wasn’t aware of it.  It makes an interesting read, though!

http://blogs.msdn.com/b/freik/archive/2005/03/17/398200.aspx

I’ve been wondering for a while why certain contacts never show up in Outlook 2010. The pattern is odd, but surprisingly common:

• When emailing someone, their contact shows up.  I can edit it, add details, and write notes.
• However, when the time comes to share a contact with a colleague, I try to dig up the business card and I can’t find it.  
• Eventually I recreate the contact, only to discover that it says “You already have this person in your list.”

Apparently this teaches me that I didn’t understand a new feature called “Suggested Contacts.”  Outlook maintains a separate list of everyone you email and keeps it handy.  Apparently I just wasn’t aware that “Suggested” contacts where physically separate from regular contacts.  I dragged and dropped everyone from Suggested to Contacts and all was well again.

We all know that software engineering isn’t really estimatable in the same way that, say, welding a steel girder is estimatable.  It’s possible to look up serious, scientific research into the amount of time it takes to weld something.  But nobody writes articles about how long it takes to build a red-black tree indexed off of a 20 character string and an integer, or how long it takes to create an Excel file parser.  Why is that?

Compared to mechanical engineering, software engineering has a number of benefits and drawbacks.  Software is essentially free; a good open source library appears to cost nothing whereas steel and electricity have known, market based costs.  On the other hand, it’s possible to waste tons of time evaluating an open source library for its suitability to a project; but steel has a limited set of metallurgical tests you can perform to ensure that it’s usable.

The key difference, though, that relates to estimating is this:

• The outputs of a mechanical engineering task are objectively definable.

Think about this for a bit.  A mechanical task to build a bridge has rigid criteria: the amount of weight it holds; the amount of wind sway it can accomodate; the distance it can expand or compress as the temperature changes.  

But when you’re writing a software program, your success and failure is not objective.  Success might be defined as producing an output for a given input, but the complexity of modern computers means even a tiny program can have a range of inputs wider than the number of grains of sand on the beach.  

Many programs even depend for their success or failure on the complexity of their user interface; an area that can’t really be objectively defined at all.  So instead you have to categorize your project as accomplishing a number of key features defined by a business requirement, or story card, or test case.

Even then, things can be wrong!  The tiniest issue can send a schedule astray.  And often, it’s a big thing that is missed: lots of things can go wrong with requirements.

So what do you do?  Is it hopeless?

Well, no.  What you can do is acknowledge that your estimates are incomplete by definition.  Working within that realm, there are a few things you can do.

• Estimate the number of potential risks between you and the goal.  If you think there are three or four unknown hurdles between you and the completion of the software, estimate based on the number of hurdles rather than the code that is fully known and understood.  Your time will be taken up researching and developing solutions to unknowns; the known stuff will always be easy.
• Imagine you are working on an artwork.  You can easily cover the canvas in blue paint in five minutes, or you can do a Mark Rothko and paint it excruciatingly over weeks until it has a subtle brilliance.  Figure out how long you want to spend, rather than how long you think you will take.
• Ideally, you should use Agile or Scrum or another iterative development method.  Build what you know to be critical foundation first, and continuously re-evaluate your estimates each day.  Every time you make an improvement, re-think the requirements to see if the work you are doing can be done better with less effort.

The common thread here is that, anytime you ask for a software estimate, just remember that the estimate will change when the project becomes better understood.

We make lots of databases here at the office.  Often they’re play databases, or restore databases, or test databases.  Since they rarely progress from development status to production status, they need to be set up with simple recovery model so they don’t collapse under the weight of the dozens of gigabytes of transaction logs my programmers pump in every day (at least, until Western Digital’s factory comes back online and we start buying hard drives again).

I was annoyed that my scripts were hardcoded to shrink transaction logs on a database by database basis.  This meant that anytime a programmer added a new database and didn’t tell me, that one could grow and fill up the disk.  So instead I wrote a single stored proc that resolves all transaction logs at one go:

DECLARE @Script nvarchar(max)

SELECT @Script = @Script + ‘USE ’ + QUOTENAME(d.name) + ‘;

DBCC SHRINKFILE (’ + QUOTENAME(f.name) + ‘); 

‘

  FROM sys.databases d

       INNER JOIN sys.master_files f ON f.database_id = d.database_id

 WHERE d.recovery_model_desc = ‘SIMPLE’

   AND d.state_desc = ‘ONLINE’

   AND f.type_desc = ‘LOG’

   AND d.name <> ‘master’

   AND d.name <> ‘tempdb’

   AND d.name <> ‘model’

   AND d.name <> ‘msdb’

IF (@@ROWCOUNT > 0) BEGIN

 PRINT @Script

 EXEC (@Script)

END

Why does this work?  First, we use the SQL server internal data structures to identify databases with simple recovery which are currently online.  Then we exclude the system databases which shouldn’t be part of this process, and prepare a SQL statement to call DBCC SHRINKFILE() on each developer’s database.  SQL provides the nifty ‘EXEC’ ability to run that query - and you’re off to the races!

With the comments from some analysts today that social gaming is flat or unsustainable, let me mention something that may be clear to people on the inside but might not be visible to the outside:

Social games, and mobile / iPhone games, are designed to exploit platform bugs.

What does this mean?

• Some facebook games became popular because they exploited the ability of applications to generate unlimited spam on facebook feeds, when facebook was becoming popular.  They gained free advertising exactly at the moment when people were receptive to it.
• Some iPhone games exploited the difficulty users had navigating the iPhone app store.  The apps that were in the “top free” lists generated lots of eyeballs, and eventually lots of conversions, simply by being near the top when people were searching.  It’s much easier to settle for the top app than to sift through page after page of stuff.
• In the past, old mobile phone games and services created phenomenal amounts of revenue by tricking phone users into texting something to a shortcode.  They then enrolled the phone subscribers into a monthly service that they didn’t understand, and they benefited from the fact that phone bills are hard to read - many of these customers didn’t know why their costs increased.

All of these bugs - and many others - are in the process of being resolved by the platform owners.  When these bugs are corrected, games will have to compete in an entirely different ecosystem than the one they were familiar with before.  Their process of natural selection will suddenly have to adjust to different fitness criteria.  Some games may persist, other games may not.

What many companies do, however, is constantly push the edge of the bugs and attempt to refine their viral appeal.  This kind of A/B testing and focus-grouping generates the highest possible effectiveness out of every exploit, but separately publishers still have to generate the kind of lasting appeal that builds a franchise people want to play.