Technical Design

You still need the Proof Of Concept

When was the last time you did a Proof-of-Concept (POC) ? Not sure - well let me pose another question...When was the last time you embarked on a technical project/task that had a considerable degree of risk in it?

IMHO one of the primary responsibilities of the project stakeholder is to mitigate the risk associated with the technical components of the business. Let's think about that for a minute. What risks are there, and how do you mitigate them? Well apart from the obvious and well documented issues like high availability, application scalability, disaster recovery, data loss, security breaches, project overrun, etc one risk that impacts on the engineering team is the occasional, or often, reliance on 3rd parties for significant components of your technical offering.

Sure, your engineering team might by LAMP/.Net/RoR domain experts and are very comfortable working in an agile environment with AJAX-y interfaces and all the bells and whistles of modern "web 2.0" applications, but as time-to-market is important and in a world where open APIs and SaaS are becoming more prevalent, invariably you'll eventually want to integrate with other service providers.

Building in this dependency on an outside party inherently poses a risk that you want to assess before making a commitment to go that route. In some cases the risk is easily assessed by reviewing the subjective feedback and experience of others. In other cases the risk is harder to quantify. e.g does the operating system and firmware of smart phone W from telco X enable you to do feature Y using language Z ? A java/brew/symbian domain expert may know the capabilities of the language/platform but it's unlikely that they will be familiar with the latest offering from Nokia or Apple, and the restrictions (if any) placed on the phones by a given carrier.

Regardless of the domain expertise you think you have in-house, it's often prudent to commit to a POC to mitigate the risks introduced. When you think about it, the POC is really the first step in any project that involved dependency on unproven technical components. If it's not, then be aware that the risk you are exposed to is carried much later in the development cycle and therefore becomes more expensive, or impossible, or mitigate late in the cycle.


Time to Deliver

Often there can be a disconnect between what management thinks will happen and what actually does happen in the development cycle due to many common scenarios. These include:

  • management bringing forward the real deadline in order to build in a buffer for overrun;
  • management not understanding the required effort to do certain things (a communication failure between technical and non-technical folks);
  • engineers adopting the ask-for-clarification-when-I-get-to-that-part approach (this is often an unfortunate byproduct of agile development methodologies);
  • a project stakeholder not being available for timely feedback when clarification of some component of the task is required by the engineering team
  • engineers giving time estimates that do not include time for adequate testing, and/or are based on an incorrect appreciation of the scope of the work (another communication failure); and
  • the ubiquitous scope creep.

If not dealt with correctly these factors can add considerable pressure to the engineers in the trenches doing the technical work and greatly inhibit your ability to deliver on time.

To maximize your chance of meeting the deadline:

  • tell the engineers what the real deadline is (if known), and advise them of the desired deadline for "code-complete", with the subsequent time being used for review/testing/patching.
  • ensure that the developer understands the task at hand. The days of writing detailed specifications are long gone, but there's no excuse to not provide a basic verbal briefing followed up by a bullet-point summary email or wiki page so the decision process is documented and the task scope is clear to all
  • prioritize the sub-elements of the task, and have the engineer do them in priority order. If the deadline is hard then you have the option of dropping the non-essential components of the task. If the deadline is flexible you can decide whether it's best to push it back whilst the remaining features are done, or ship without them.

If this all sounds like Project Management 101 then that's good, but there are many cases where the basic survival principles are ignored by technical managers. And ignored at their peril !


Going through the Greeks

Time to Market is seen as an important factor when building out the technology underpining a startup environment. Although there have been some spectacular contradictions to the "1st mover advantage" notion (Microsoft's C# language vs Java, ... ), I certainly agree with this idea as even the best business plan is going to find it harder to get traction and exposure in the market place if your competitors have beat you to it. The VC community is well aware of how much harder it is to complete in well-established market places which is why it's in your best interest to get out a version of your product or service as soon as possible if you are indeed in a well-established market. (Side note: you will find it significantly harder to raise capital if you are entering into a crowded, mature market. In that case think differentiation and market niches.) I also believe that the ability to constantly innovate and update your product, without significant distribution costs or end-user hassle, is one of the main factors driving the popularity of Software as a Service.

Rather than spending years developing your product before bringing it to market, out of necessity many startups use a highly iterative approach. Because of this you often see startups labelling their services with terms used by engineering teams to describle interim versions of a product: "alpha", "beta" and "gamma", a practice I refer to as "going through the Greeks". The idea being that this labelling indicates to the consumer that the product is still undergoing a significant degree of development. Although, to be honest, you would need to be familiar with software development terminology to make this connection!

Conducting progressive releases has it's pros and cons. On the downside:

  • it give your competitors early access to your product allowing them to copy it;
  • it gives your competitors a glimpse into your longer term strategy; and
  • you risk losing appeal with your target market if the product is not feature complete to an extent that appeals to your target market.

On the positive side:

  • you get earlier exposure in the market place allowing you to glimpse the likelihood that your business model has merit;
  • you are effectively announcing your presence to your customers and potential suitors;
  • you get early feedback from your initial users which can help you refine further development and marketing efforts; and
  • once the core architecture has been implemented, your engineering team can focus on smaller chunks of development and refinement (aka "phased development and release").

Naturally, it is a management decision to decide what can be released in beta for strategic purposes but it's prudent to be prepared for this phased development and release process, and to establish internal procedures that allow you to "release early and release often".