Category Archives: Uncategorized

Successful Software Platforms are the Byproducts of Successful Businesses

Twitter Summary: Startups need their current business to be successful and self-sustaining before they place serious effort in building a general platform.

I have a new post up at blog@CACM, “Successful Software Platforms are the Byproducts of Successful Businesses“ which was originally brought on by reading startup plans that all highlighted that they would have a general software platform in the middle of a virtuous cycle. In looking at these business plans, I realized that any substantive effort making the platform production-ready, would likely divert efforts from making the company profitable or able to deliver on its original mission. Exactly the type of expenses startups typically don’t have the resources to spend.

In doing a little research for the article, I was pointed to Chris Devore’s article about the value of platforms outside of software development. Examples include franchises like McDonald’s/Subway.  and Avon.

You should name your dogs, but number your cattle.

Twitter Summary: Naming conventions for scaling systems.

Naming machines used to be one of the fun parts when buying new machines to develop software. At one company we named the machines after characters of the Brady Bunch (Greg, Marcia, Jan, Bobby). At the University of Washington, a research group named their servers after fish (Sturgeon, Smelt, Scrod). At, the first servers were named after flesh eating fish (barracuda, piranha, tiburon). The flaws of this approach readily became apparent because we ran out of names when more machines were purchased. The solution is either to add the characters of another favorite TV show or create a scalable naming convention.

By adopting some standardized naming convention, it becomes easier to keep track of the systems. Naming standardization practices typically included adding a prefix of the machine role so that they could be easily grouped in printouts and display (search-, web-, desktop-, db-). Other ways to make machines easier to identify is to put their owner’s name in their name like Apple and Windows do by default for their personal computers. The problem with these fleets is that frequently they became specialty machines or are built in a fashion that they can’t be easily renamed and reused should you need to re-provision the systems for new roles or users.

If you are managing fleets of servers as in any one of Amazon, Google’s or Microsoft’s datacenters, the only option you have is to just naming a random string for each server name to avoid naming collision with a prefix only for the physical location of the server. The role of each of the servers will be allocated based on the role required for each machine based on the demand of the day. By naming the server randomly, and mapping its functionality based on a separate software system you can get the flexibility required to provision and re-provision machines as opposed to tying the machine to some functionality based on the name.

It is all a far cry from having a small number of systems to write software and deploy a web application. However, if you are growing a company for success you should probably have some standards to name the systems you work with daily, and having naming conventions for servers that grow without bounds. In other words, you should name your dogs, but number your cattle.

How Much Software Testing is Enough?

I have a new post up at blog@CACM, “How Much Software Testing is Enough“, about the value of Test Driven Development and the benefits of testing even when you don’t feel you have the time to do it well.  Included with this post is a vignette of one the most memorable bugs in my career as a software developer since it happened on a memorable date and the poetic justice from the book that triggered the problem.