18 Comments

Summary:

Just like with golf, technology is as much about ensuring that your bad hits are recoverable as it is ensuring that you make great ones. Here are 10 common mistakes made during platform development — and the ones we believe are the most important to avoid.

Just like with golf, technology is as much about ensuring that your bad hits are recoverable as it is ensuring that you make great ones. We’re all going to have failures in our careers but avoiding the really big pitfalls will help you keep your company on the right growth path. Here are 10 common mistakes we at AKF Consulting see made during platform development — and the ones we believe are the most important to avoid. 

1) Failing to design for rollback: If you’re developing a SaaS platform and you can only make one tweak to your current process, make it so that you can always roll back any code changes. We know that it takes additional engineering work and testing but in our experience, such effort yields the greatest ROI.

2) Confusing product release with product success: Do you have “release” parties? Don’t — you are sending your team the wrong message. A release has little to do with creating shareholder value. Align your celebrations with achieving specific business objectives, such as increasing sign-ups by 10 percent.

3) Assuming a new Product Development Lifecycle (PDLC) will fix issues with missing delivery dates: Too often CTOs see repeated problems in their development life cycles, such as missing release dates, and wrongly blame the development methodology. Make sure you’re fixing the right thing — lack of ownership or involvement in and/or incomplete understanding of the current PDLC are among the most common root causes of late dates.

4) Allowing history to repeat itself: Organizations don’t spend enough time looking at past failures. The best and easiest way to improve your future performance is to track your past failures, group them by causation and treat the root cause rather than the symptoms. Keep incident logs and review them monthly to identify recurring problems.

5) Scaling through third parties: If you’re a hyper-growth SaaS site, you don’t want to be locked into a vendor for your future business viability; rather you want to make sure that the scalability of your site is a core competency and that it’s built into your architecture. Define how your platform scales through your efforts, not through the systems that a third-party vendor provides.

6) Relying on QA to find your mistakes: You cannot test quality into a system and it’s mathematically impossible to test all possibilities within complex systems to guarantee the correctness of a platform or feature. QA is a risk mitigation function and it should be treated as such. Defects are an engineering problem, and that’s where the problem should be treated.

7) Relying on “revolutionary” or “big bang” fixes: The degree of success of complete rewrites or re-architecture efforts typically ranges somewhere between not returning the expected ROI and complete failure. The best projects — and the ones with the greatest returns — are not revolutionary but evolutionary. Go ahead and paint that vivid description of the ideal future, but approach it as a series of small steps.

8) Not taking into account the multiplicative effect of failure: Every time you have one service call another service in a synchronous fashion, you are lowering your theoretical availability. If each of your services is designed to be 99.999 percent available, then the product of all of the service calls is your theoretical availability. Five calls is (.99999)^5 or 99.995 availability. Eliminate synchronous calls wherever possible and create fault-isolative architectures to help you identify problems quickly.

9) Failing to create and incent a culture of excellence: Bring in the right people and hold them to high standards. You will never know what your team can do unless you find out how far they can go. Set aggressive yet achievable goals and motivate them with your vision. Be a leader.

10) Not having a business continuity/disaster recovery plan: No one expects a disaster, but they happen, and if you can’t maintain normal business operations you will lose both revenue and customers. A solid business continuity plan explains to everyone how to operate in the event of an emergency. Even worse is not having a disaster recovery plan, which outlines how you will restore your site in the event a disaster shuts down a critical piece of your infrastructure, such as your collocation facility or connectivity provider. Our preference is to provide your own disaster recovery through multiple collocation facilities.

Marty Abbott and Michael Fisher are partners with AKF Consulting.

  1. Three comments. One, this feels very much like consultant-speak and not real business strategy, as these items are mostly catch-all platitudes and not super specific or clearly actionable.

    Two, the post speaks about ‘platform development,’ but again, the feedback only loosely anchors to the fundamental question of what makes a platform. You could have changed the title and sub-text to ‘How to Create Really Scaleable Widgets’ and most of the text would have held.

    Three, the biggest mistake I have seen with platform development is confusing 1.0 and 3.0 requirements. Platforms need to be designed with some governing lifecycle set of goals and objectives in mind but need to solve 1.0 problems for anyone to care. Too often, you see 3.0 vision that doesn’t solve 1.0 problems, or 1.0 tactical goodness that doesn’t scale. That is the biggest mistake I have seen repeatedly, a construct I call the 1.0/3.0 Paradox.

    Here’s a recent post that speaks to the 1.0/3.0 Paradox:

    Threading the Needle: Essential Truths for Early-Stage Entrepreneurs
    http://thenetworkgarden.com/weblog/2008/06/threading-the-n.html

    Cheers,

    Mark

    Share
  2. Raanan Avidor Monday, June 30, 2008

    * You should do “release” parties AND “product success” parties. Reaching a release is a big step for RnD, QA and the whole company, you can’t just say it is not important, they ARE important milestones that should be celebrated.

    * Relying on QA to find your mistakes is a big mistake. QA is there only to find out the bugs that the development cycle missed and maybe have a more holistic approach to the product that development a lot of the time lose due to the development process.

    Share
  3. Definitely seeing the consultant-speak here as well.

    Launch parties are a way to reward the engineering organization for a job well done. Success in the marketplace is something that happens after a launch and is largely out of the control of the engineering organization. If you want to make your hard-working software developers feel even more beat down, throwing parties to commemorate the successes of the sales and marketing organizations sounds like a terrific way to do it.

    Share
  4. Looks like a pretty good list to me, and specific enough to help make both tactical and strategic decisions (which undermines charges of ‘consultant-speak’).

    As for separating the engineering mission from the company mission, well, I’d say this is paving the road to ruin. There is only one mission.

    Can’t disagree with the argument that you have to solve some problems completely with 1.0 or it ain’t worth dreaming about 3.0.

    Share
  5. [...] Platform Development Mistakes 06.30.08 (5 seconds ago) | No Comments Over at the Gigaom Blog the people from AKF Consulting have published a list of the 10 biggest platform development [...]

    Share
  6. Here at Zynaptics we have one more to add:

    Always make sure that an error message can be traced back to the offending code and data. You have to include this functionality in your error handling and user messaging.

    How many times have you have received a bug report that had some vague description: I was importing the file and got a “Object cannot be null”?

    When you look at the import routine you have 5000 lines of code and the user was importing 250,000 records.

    Much better to get this error: “App Error: Object cannot be null. PriceCalcFunction on record #45514″. Imagine how much time you’ll save finding and fixing the issue. This benefits the users and the development team.

    Finally, when you take this approach it tells people we take bugs seriously so test them out before you deliver code.

    Share
  7. ::[ Allowing history to repeat itself ]::

    This one needs a lot more attention in the industry. Of all the company I’ve worked for over the years as a programming contractor I’ve never been in a planning meeting that discussed past project mistakes and how to avoid them or about successes and how to repeat them.

    Share
  8. About “Failing to design for rollback: If you’re developing a SaaS platform and you can only make one tweak to your current process, make it so that you can always roll back any code changes.”

    This is easier said than done. Designing rollback and an ‘idempotent state machine’ is one of the difficult problems that any designer can face. The amount of code that is written with rollback enabled would probably be at least 2x the size of code that you would write without rollback.

    I am not saying we should not do rollback, it’s just that you need to keep the extra time and effort in mind while designing rollback.

    Thanks,
    Mukul.

    Share
  9. I’m glad others have pointed out the importance of release parties. The time approaching the release is the hardest time on your developer and verification teams, and they have likely ungodly hours to deliver the goods. Release parties are unquestionably an excellent idea, and a great way to reward that work.

    If you want to exclude the marketeers and sales guys then do but I doubt they thank you for that!

    Share
  10. Have to agree with the couple others who are supporting release parties. If you tell your developers that release is not an important milestone for the business and that “signups”, which are sales-driven, are all that matters, you are going to absolutely destroy your developers’ morale.

    My response to such talk, as a developer, would be one of three things:
    1) If I am ambitious and self-confident, find a new job ASAP.
    2) If I am passive and self-confident, throw it back in management’s face next time they are demanding unpaid overtime to meet a release date, pointing out how “release is not an important milestone for the business”.
    3) If I am passive and not self-confident, reduce the effort I put into my work on a daily basis, to make up for the unrewarded, unrecognized stress and effort that goes into a product near release.

    A release party doesn’t need to be sanctioned by the CEO, and shared by the whole company. But it is important for the developers to blow off some stress and get recognition, at least by their immediate managers, for the blood, sweat, and tears it took to get the product shipped.

    Conversely, if the product ships according to spec, and it still flops, that is almost NEVER the DEVELOPERS’ fault. They followed a plan, a bad plan. And the creators and custodians of the bad plan are the ones who should be flogged.

    Share

Comments have been disabled for this post