Introduction

My name is Nicolas Juneau and I am Coveo’s CFO (Chief Failure Officer). As the blog review team has yet to unpack a huge backlog of articles to review, I took this opportunity to write on this blog about a subject nobody wants me to talk about: patterns for project failure.

We all heard the conferences, we all read the articles: we know how to ensure a project’s success. After all, software engineering is a tried and true discipline as old as civil engineering. Julius Caesar successfully designed, wrote, and deployed his very own cipher back in the Roman empire, so we should have this figured out by now. Today, let’s take a break from articles teaching us what to do and let’s focus on something more entertaining: striving for failure.

Let me do what we always try to do on Star Trek: hopefully entertain you, perhaps even make you laugh a couple of times. And when your guard is down, slip in a heavy idea or two…

– Gene Rodenberry, “Inside Star Trek”, 1979

For the purpose of this article, we will develop a fictional project that involves the following disciplines:

• UX
• Frontend development
• Backend development
• Infrastructure
• Security

For each discipline, failure patterns will be described. Nobody should feel shame if they recognize such patterns in their own experience. It only means that you are human working in a human organization.

The project

As a Coveo employee, a colleague came to you with the following project opportunity:

To build and deploy a social network tailor-made for Pug lovers. Not the toy, but arguably the most lovable dog. For brevity’s sake, sales and marketing already came up with the name: PikPug.

The details of the project are intentionally left vague.

Step 1: Business case (non)-analysis

PugBook is bound to be a surefire hit: market research shows Pug lovers are all over the place and advertising opportunities are ripe.

One might be tempted to run with the idea immediately, and this would be one of the first steps into a failing project: ignoring the company’s core business and values.

Multiple issues are at hand here:

• Your colleagues, who joined Coveo to work in the complex field of machine learning will likely not be too delighted with the opportunity to expand their knowledge to the world of Pugs and social media. As unbelievable as it may sound, not everybody loves Pugs.
• Such a venture will likely appear dubious to many parties inside and outside the company. As a customer, I might wonder why effort is spent on such an endeavor (no matter how lovely it is) instead of spending effort into the solutions I’m paying for right now. As a director, I would likely have a fun time trying to justify this investment with regards to current company objectives.
• Should the project be greenlit anyway, it could compromise current efforts and objectives. Unlike popular belief, human resources are not like printer cartridges (interchangeable and replaceable at any given time). Why the industry still labels human beings as resources is a subject best left for another blog post.

Besides all the aforementioned red flags, you take matters into your own hands and go ahead with the project. I can tell you right now that the probability of this actually happening for real at Coveo is near 0 - but, there is a theory that says that in a parallel universe, it happened.

Step 2: You landed at Agility! Go directly to step 3!

Project manager must be the most ungrateful position to hold as these super-humans must constantly try to keep a fine balance between reckless speeding and analysis paralysis. One workaround that can be employed with almost guaranteed failure in the long term is to use agility as a means to identify issues in planning while simultaneously using agility as an excuse not to address them. This usually translates to:

• An absent roadmap
• An absent budget forecast
• An unclear team commitment (how many, for how long)

Perceived benefits include:

• Short planning sessions (read: absent)
• Lean budget planning (read: absent)
• Supple objectives (read: everchanging)

The overarching mentality is essentially that you don’t need to bother with what happens in the next weeks or months unless you’re planning to go to the moon.

Protip: When questioned about the utility of planning ahead, deal in the extremes. Examples such as “We’re not building a space shuttle” or “Do you know how much they spent on [insert NASA mission of your choosing]?” will ensure a swift rebuttal, supported by your good understanding of what NASA missions entails. Creating the fear that a project might cost as much as a space shuttle in terms of planning is the perfect way to avoid doing any planning to begin with.

Step 3: Segregate UX and software development

Now that planning has been tackled, let’s talk about UX. One commonly applied pattern is to keep a safe distance (no less than 1KM open space, 500 meters closed space) between UX and developers. Perceived benefits being:

• Design meetings involving both UX and developers will never take place, saving some precious time on the drawing board (it costs less to apply changes to the user experience once coding starts) while simultaneously freeing developers to implement the solution.
• Feedback loops are perfectly airtight and concise (UX and developers can’t benefit from each other’s experience).

The central theme of the pattern being that UX is a separate process from software development, much like security is (more on that later).

Step 4: Skip software engineering

One applied failure pattern is that software engineering practices are useless in the face of all-star coders spinning up POCs faster than the time it takes to put together a PB&J. Why bother spending time thinking about what you’re about to code and not code it already? After all, the reasons are aplenty:

• Defining software requirements, especially with frameworks such as FURPS+ or worse, ISO/IEC 25010:2011 is unnecessary. All people think alike and share the same perspective about the project. Having a standard on how to communicate requirements is just another burden.
• Time spent drafting software processes, especially with well-known languages such as UML or BPMN, is time not spent coding. Besides, UX does not have access to those artifacts and just like UX, the most cost-effective time to tackle core issues is while the code is being built.
• Keeping an Architecture Decision Record (ADR) is time-consuming. The context in which the decisions are made never changes and will never invalidate your decisions in the future. You’ll save a lot of time revisiting decisions you should not question ever anyway. If you’re onboarding new employees that have a hard time getting up to speed as a result, it’s their fault they weren’t there when the decisions were made.

In short: get to code (i.e., real value) as fast as you can.

Step 5: Always invent it here

Many are aware of the NIH syndrome - and for good reason. As software developers, resisting the temptation to invent it ourselves is like resisting the ever-present chants of the dark side. The temptations come in many forms:

• Your terms, all the time: no time wasted on checking software licenses, background-checking the companies behind them.
• Your code, the way you like it: no time wasted on conforming to other software communities’ contribution guidelines. You are the guidelines.
• Your own release cycle: are other people moving too fast? Or maybe too slow? You do your own thing, at your own pace.
• No need to invest in security scanners: your internal libraries will always be more secure. No 3rd parties, no vulnerabilities!

Although not quite in the realm of “Not Invented Here”, a closely related phenomenon is forking. The neat thing about open source software is that you can make it your own. Key benefits include:

• Internal forking: no need to spend time trying to get your fix upstream, just ship it internally.
• Reduced license costs: Community support ended and you don’t pay for commercial support? Keep the patches coming yourself!

Step 6: Automate infrastructure work later

Many tools exist to automate infrastructure work: Terraform, Cloudformation, or Ansible to name a few. However, deploying those tools efficiently requires a lot of effort. If you don’t have time to automate your infrastructure now, you won’t have time later either. Just like UX, implementing infrastructure automation late in the game costs much less than doing it in advance. After all, what’s not to love about pages of AWS Web console screenshots, Bash scripts and good old elbow grease?

Step 7: There are no 9s after 100%

You made it from steps 1 to 6 and your product has been deployed in production. People are using your product and the future looks bright. However, you want to ensure that PugBuddies remains eternally so: functioning all the time, in tip-top shape.

This is where one sneaky failure pattern rears its head: being unable to fail. You want your product to be perfect, and you know you can make it:

• Simple SLOs: , always on, all the time. Pug love is eternal and cannot fail. CAP theorem be damned, your software will scale, distribute, and remain perfectly consistent forever.
• Everybody on call, 24/7, at the same time. Don’t overthink the on-call schedules - your software is well built. If your people keep getting paged, it’s because your piece of software is broken, not because your alarms are defective or unreasonable.
• If it’s not green, it’s catastrophic. Incident management becomes incredibly easy: either the whole system is in perfect health, or it’s completely dying. Resolving alarms takes less time than figuring out why they occur and why they are important to you. Focus is applied on the causes. Bonus points: no need to think about error budgets anymore.

Step 8: Security?

If there is some time left, security measures may be put in place on the off chance that they’re not already there. Security is a lot like UX: it’s best done separately, fixed most efficiently once in production. Your well-spent budget allows for the following security considerations to be put in place… Scratch that, you’re out of time and budget. Assume security is good.

Epilogue

By now PugVogue should be up in production, with a team happily maintaining it day to day in a healthy manner. It will stand as a shining beacon of innovation inside your organization, a testament to your everlasting creativity. Please excuse me, my pager is buzzing!

Conclusion

I would hope everybody recognizes themselves in one way or another while going through this article. Whether it is your past self you are seeing, the self you wish to improve, or a self you wish not to become, you now have all the tools in hand to fail in a consistent manner. You might be tempted to ask, is Coveo then impervious to project failure? The answer is no. And that’s part of what makes a good defense against it: we recognize failure as a possibility, not a fatality. We know that to err is human, and how to learn from our errors. We don’t know perfection, but our collective experience most certainly knows disaster - and our talented staff will do everything in their power to make your projects with us a success.