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. You’ll likely 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 on better expressing your needs.

One important point to always keep in mind is to be conservative. Consultants will attempt to pull you into newer technologies for various reasons that are 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 “the ability to produce results quickly.” Anything “productive” seems 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? 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. You might want to explore different software development methodologies for a deeper understanding of these cycles.

Incorporating security into this cycle, such as through a DevSecOps maturity model, can ensure that security is built
in from the start rather than tacked on later.

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

The 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 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 change between deployments. In part 2 of this series, I will discuss in greater detail 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 the 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, hindering continuous integration. 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.

This can only work well if context switching is as painless as possible, and massive efforts are being made to fine-tune this specific aspect. You’ll hear much 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. Because of these market pressures, 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 return 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 are interested in longer overall projects with more milestones. 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 pushing 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.”