Show me the money!

The other evening I was talking with some software folks about technology and software development. The topic ranged over to which language is better. For those of you who have been reading my blog for awhile you know that I think these types of conversations are ignorant. Before it got too heated, I just had to break in and say, "It’s about the money." That stopped the conversation track cold because all the participants were senior level, experienced software development folk. And they know it’s all about the money. If someone pays you to write code for them...then every technology choice is some how tied to money. If it is a commercial
application then the software needs to generate revenue to pay your salary. If it is an internal application then it should save the company money. The only time that software development is only about the technology is when you write it for free.

Understanding the business impact of your technology choices is one of the differences between being an architect and being a coder. An architect will look at the problems and make technology choices that are balanced between short-term objectives (time to market, stability, performance, scalability, security, ...) and long-term objectives (maintainability, enhance ability, marketability, ...). Developers who make pure technology choices (i.e. without considering the business aspects of the choice) are far more likely to build a product that will fail.

Over the years I’ve had the opportunity to work for quite a lot of startups. Startups that were founded by pure technologists tended to fail because the leaders didn’t understand marketing and sales. But not just marketing and sales from the perspective of what the marketing and sales teams needed to do, but in terms of what the technology needed to do to satisfy a market. Any market.

I have also worked for companies started by sales folks who understood the sales-side of things but didn’t understand the technology. These companies are interesting because they jumped right out of the gate but the technology wasn’t solid enough to standup to customer use. (Just for the record, I often come in late on companies.)

Companies with the highest success rates were those where the founding teams were balanced and could communicate between the technology and sales sides. Building high quality products, using the right technologies for the problem space, in a market that needs the solution.

Just remember the old adage, "If all you have is a hammer, then everything is a nail." And keep in mind what that means. These days the software community has a wide assortment of tools to choose from. There is a smorgasbord of choices. We have today the equivalent of my father’s SnapOn tool chest. Use it.