Choosing Technologies for Your Web Startup (Part 1)

You have a great idea, a viable business model, and investors lined up. Now, you need to build your website. 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 they put you in. 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 advice on interpreting what consultants tell you and how to better express your needs.

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 seems that anything “productive” is good, and you should strive for more.

Who wouldn’t want to move more quickly from product design to finished product? However, “productivity,” as 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, in fact, slow?

Part of the confusion is due to the process being obfuscated. Software engineers are extreme specialists, and outsiders have little clue about what 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, and 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. The slowness could mean three things in this context:

Want a free brand review?

Answer 5 short questions and we will send a custom report with actionable insights and specific actions you can take to build a stronger brand.

We just emailed the info to you.

Email Address

1) Some components are slow. Coding used to be the target of such complaints. Older programming languages and environments are often accused of being complex 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.

In good-old C code, many engineers find themselves coding fastest using minimal text editors and command lines. 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 severe 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 is that you should not be overly impressed by “easy” languages or platforms offering “zero” deployment.

2) Switching between components is slow. The reasons for this are both bureaucratic and technical. Each switch involves moving into a new mode and style of work, a new set of tools, and sometimes different programming languages and platforms. It will likely also include shifting of responsibilities within the team.

This “context switching” can be excruciatingly slow, as team members try to catch up with the switch, struggling to meet common deadlines that may not suit their tasks’ changing circumstances, while others have to wait idly. Fed up with this frustration, newer project management styles try to allow the team to work on several components simultaneously. Team members are thus constantly switching contexts.

The only way this can work well is for context switching to be as painless as possible, and there are massive efforts to fine-tune this specific aspect. You’ll hear a lot of talk about “agile methods,” “continuous integration,” etc. My advice is not to put all your eggs in this basket. If the price of fast context switching is adapting immature programming languages or nerve-wracking work styles, then it’s not worth it. Consider this a secondary, optional optimization.

3) There are too many switches between components. This factor, too often overlooked, ends up being the most straightforward to optimize, and with the best results. It’s simple math: even if context switching is slow and clumsy, even if your project management is haphazard and inefficient, it won’t hurt you if you don’t have to switch often. Why is this overlooked? There are two reasons. First, it seems counterintuitive to speed things up by spreading the cycle out and lengthening the components. Second, clients like you are often impatient. You get nervous about an obscure development process, about weeks and months going by without visible results. You want to “see the goods,” thus forcing the consultant into a less efficient process requiring many context switches leading up to milestones, and spinning off major efforts to optimize the process. It’s because of these market pressures that consultants try to sell you “productivity.”

Why do consultants tell you otherwise when they should know better? Because they have their own interests in mind. Let’s go back to “productivity” meaning “the ability to produce results quickly.” What results? Think of how consultants make their money: projects are defined in terms of milestones, each of which requires the client signing off a set of deliverables. This contractual process enforces a strange, condensed development cycle, where prototypes and other visible results are more valuable than the project’s total time span. In fact, consultants have an interest in longer overall projects with more milestones along the way. Their interests conflict with yours.

This is the crux of my argument: old, reliable technologies lead to faster overall development than new technologies touted as “productive.” Seek “reliability” rather than “productivity.”

Play it safe. First, I recommend being unimpressed by consultants trying to push you into new technologies, especially if they tout “productivity.” Instead, keep challenging consultants to come up with plans using tried-and-true technologies. They will fight you on it: newer tech means longer projects and more profits for them. Second, unless you absolutely need functional pieces ahead of time, don’t have the project milestones be about the consultant “showing you the goods,” but have them tied to whatever would minimize the number of context switches. For example, milestone 1 might not have any significant testing yet, and milestone 2 might have no deployment. The cost for you is that deliverables for milestones would be more difficult to evaluate: say, a written report rather than a functioning demo.

But, let me let you in on another little secret: many of these “demos” are bogus. Consultants spend a lot of time creating them for you in order to impress you and pass the milestone, but they might be utterly separate from the main line of product development. The insistence on “seeing the goods” is a waste of time and money.

In part 2 I will delve into a few popular platforms and programming languages, and examine the them in terms of “reliability.”