We had a social lunch today, seven people, all involved with web or application development. At one point, someone asked something along the lines of, “What is your obligation to customers to use ‘standard’ technology that will be around when they need to update their app?” Another person mentioned the ease of getting Java programmers; shouldn’t something like that be one criteria?
I casually tossed off: “Well, if it’s a small company, that attitude will cause failure, because it’s not entrepreneurial.” The topic deserves a more thoughtful response. My bias is that effort should be focused on potential, not risk. Risk is something to manage once you’ve decided to reach for a potential. There are a few intermingled threads that occur to me:
* Any custom software will require on-going maintenance. Any customer who doesn’t know this should be fully informed. Some very successful business-people will refuse to believe it, because they don’t know anything about software. Actually, it’s not about the software, it’s the fact that they haven’t looked closely, over time, at their business. The business requirements change, hello; therefore, business processes encoded in software will have to change too. The cost of software platform maintenance pales in comparison to the cost of determining and implementing the business logic. Non-software business people who are overly concerned about cost are usually the ones who cannot describe exactly what they want. That is what drives costs, not the platform. The business people who come to you with a written specification usually already know the ballpark cost, and you’re immediately discussing the project at a much higher level – feature trade-offs, deployment risk factors, strategic opportunities for version two, etc.
* “New” technology becomes “mainstream” technology through the momentum of use. If no one uses something, it dies off, orphaning existing software. This isn’t quite literally true, because the software will continue to work virtually forever, but eventually the business logic changes (or you have to patch Windows) and then you have to update the code. It could take years for this occurance, but it is a downside risk to consider. So custom software developers rarely use something brand spanking new on a customer project until it is proven somehow.
But what does “proven” really mean? It is important to consider the case where something new takes off fast. At lunch we were specifically discussing Ruby on Rails. Two of us thought it looked pretty good, and one person was thinking about a small test project to check it out. Ruby on Rails has the opportunity to take off quickly because Basecamp was built on it, and everyone who’s used it knows that Basecamp is an awesome product. When they find out it was developed in two months by one guy they cannot believe it. Why only two months? Ruby on Rails, supposedly. Sometimes “new” becomes “mainstream” very quickly. It appears that this could happen to Ruby on Rails this year. That brings with it a host of potential problems, but obsolescence isn’t one of them. [Update: The Ruby on Rails author has commented on this post.]
We should remember that everything mainstream today was once brand new. How did Java, or MySQL, or Perl, or, for that matter, C and C++, actually take hold? Enough people used them and told their friends.
* If there is legacy code, a good software engineer will just deal with it. I’ve had the opportunity to work with several world-class software engineers in my career. And universally, what top-notch engineers say is, I’ll learn what I have to learn to do the project. So if a customer ends up stranded, what they need is to find a good engineer, who will either work within the existing framework, or re-factor it for the future. So they’re paying $125 an hour instead of $75. Or $175 instead of $125. Whatever. It’s insignificant compared to the cost of the business logic. If the customer is bothering to update the application, then by definition it has value and is worth doing. If you’re simply obsessed by cost, then you’re probably investigating outsourcing anyway.
* If it’s a big company, then they deal with re-factoring and changing platforms all the time. They have engineers on staff, and it’s a constant part of their job to deal with some piece of crap code that’s 20 years old but is core to the operations. It’s brittle, and dangerous to work on because if it breaks some huge part of the org shuts down, and only the most senior people go near it. Hospitals are famous for this. Hospitals are also pretty famous for technology decisions made by administrators who are not well-informed about technical details, therefore choosing the wrong products and platforms for the wrong reasons, but I digress. (No links provided so as to protect the guilty.)
* If a small company is choosing their developer based purely on a pre-conceived language specification, they are operating from fear, and will not succeed. Entrepreneurs look for opportunities, not optimizations. (N.B.: These comments apply specifically to companies whose core product is not software. Software companies deal with these issues using more advanced methods.) Basically, the buyer is placing themselves in the hands of the developer, and they need to have a solid relationship – the relationship trumps everything else. If the developer is going to walk the customer down a dead-end, it won’t be because of technology – though that may be the vector – it will be because the developer is not accurately or honestly solving the customer problem.
Conventional wisdom says that customers need to know that the developer isn’t going to invent something new to build their app – use mainstream technologies like PHP or Perl, Apache, and MySQL, and no one gets fired. But that’s not what happened at Basecamp. The developer of Basecamp invented Ruby on Rails in order to do a good job building the customer product. No doubt the customer paying for Basecamp was fully informed, but then again, we’re back at the relationship. Innovation is not as clean as a technical specification might make it look. They took a risk, together, apparently leading to mutually-assured success.
Focus on the upside potential, and manage the downside risk, in that order. That’s where the innovation is.
January 6, 2005