You have a great idea, a viable business model, and investors lined up. Now, you need to build your web site. Likely, you’ll start by hiring a consultant or consulting firm. Consultants can be valuable resources, and good relationships with them can be key to growing your company. The unfortunate flip-side is that bad advice can lead to a stalled product, unable to scale and compete. Worse, you might find yourself locked into an expensive, tense relationship, with the consultants being the only ones who can get you out of the mess in which they put you. Because development cycles for web services are measured in months if not years, you cannot afford to make mistakes.

In this series of blog posts, I’ll offer some advice on how to interpret what consultants tell you and how to better express your needs to them.

Bottom line first: be conservative. Consultants will attempt to pull you into newer technologies, for various reasons attractive to them and possibly attractive to you. The risks may not be entirely obvious.

Part 1: The Myth of Productivity

The word “productivity” should be a red flag for you. Let’s unpack it. It seems to mean something like “the ability to produce results quickly.” It would seem that anything “productive” is good, and you should strive for more of it. Who wouldn’t want to move more quickly from design to finished product? However, “productivity,” as it is used in this context, can lead to the opposite. To understand this, we have to ask: What exactly is slowing down the process in the first place? And is it really, in fact, slow?

Part of the confusion is due to the process being obfuscated. Software engineers are extreme specialists and outsiders have little clue as to what really goes on. Software projects are fertile ground for buzzwords to take root. As an outsider, what you need to know is that there are components to the development process – drafting, prototyping, debugging, deployment, testing (all of which happen before integrating the product into its social environment) – and that together they compose a “cycle,” such that development moves back and forth between components. Slowness could mean three things in this context:

1) Some components are slow. Coding used to be the target of such complaints. Older programming languages and environments are often accused of being difficult and error-prone. From this criticism we get “visual” coding tools and IDEs (Integrated Development Environments). What you need to know is that this criticism is entirely subjective. There’s no objective speed advantage to using visual tools or newer languages. Many engineers find themselves coding fastest using minimal text editors and command lines, in good-old C code. Another supposedly “slow” component is deployment. Here, we do have measurable and sharp differences between technologies. In general, interpreted languages offer much faster deployment than compiled languages. For example, deploying PHP is almost trivial, while deploying C in a heterogeneous environment can be a nightmare. Another serious problem is deploying to moving targets, such as operating systems or platforms that are changing between deployments. In part 2 of this series, I will go into greater detail about how the choice of programming languages and platforms can affect your product, but my general advice at this point is that you should not be overly impressed by “easy” languages or platforms offering “zero” deployment.

(more…)