Wolf

  





What is a WoLF? 

The WoLF is not necessarily an individual, but a disruptive situation that requires product managers to drop everything and go into firefighting mode. In the world of software development, there’s always a negotiation between working on new features and addressing technical debt. Over-indexing on technical and security problems means you’re not focusing enough attention on delivering new features and value. But the opposite—neglecting these issues to focus solely on new features—can lead to several types of fires that require your immediate and complete attention, whether it’s the loss of data, security breaches, or an all-out product failure.

Why are WoLFs dangerous?

The WoLF will jump from one fire to the next, even when it comes at the expense of 
 value delivery. In this cycle of reactivity, where all resources are dedicated to firefighting, 
 you compromise productivity and a long-term, strategic approach to your product. 
 Plus, you’re making it impossible for your team to do anything truly new or innovative.

WoLFs in the wild

When a WoLF is left to run wild, you can end up with a wildfire that destroys your business. Take the example of Knight Capital, a financial services firm that was brought to its knees 
 by technical debt. 

In 2003, Knight Capital introduced the Power Peg algorithm. Designed to “buy high and 
 sell low” in the stock market (the opposite of conventional “buy low and sell high” wisdom), 
 it was meant for use in a test environment. In just one trade, the loss of a few cents would 
 be insignificant.

Power Peg was then left unused in Knight Capital’s codebase for a very, very long time, leaving it vulnerable to the prowling WoLF.

Nine years later, Power Peg was accidentally enabled during a software update. Thousands 
 of “buy high sell low” trades were executed each second in the real world. And it quickly added up. Within 45 minutes, Knight Capital had lost $460 million.

So, what caused this catastrophe? 

1. The flag that was used to enable Power Peg in the test environment was repurposed for 
 use in a new functionality. Thus, the program believed it was still in the test environment 
 and executed trades as quickly as possible.

2. There was no formal code review or QA process, nothing in place to ensure the software had deployed correctly, and no thresholds to stop automated trading after a set amount 
 of losses. 

3. There was no existing catalog or naming convention for feature flags, leading to a situation where engineers had no understanding of the true nature of the feature flag.

4. There was no practice of removing old or unused feature flags. The lesson is clear: neglecting technical debt in your product and letting a WoLF run wild can seriously cost your company.

The lesson is clear: neglecting technical debt in your product and letting a WoLF run wild can seriously cost your company.

Comments

Post a Comment

Popular posts from this blog

Seagull

Image
                                               What is a Seagull Manager? There’s no need to decode an acronym here—Seagull Managers are pretty much exactly what they sound like. They’re people who tend to be a little bit removed from the day-to-day work 
 on a project, so they occasionally swoop in, make a lot of noise, leave a big mess, then swoop out again, leaving the team to clean up after them.  Why are Seagull Managers dangerous? Like many other dangerous animals, Seagull Managers often have good intentions. When 
 they swoop in, they’re often trying to accelerate a process or “save the day” with their idea. 
 The problem is that they often lack context and nuance, and they take away a team’s agency and ability to find solutions on their own.  Seagull Managers in the wild You might see a senior VP of engineering, for example, who walks in one day and t...
Read more

Zebra

Image
                                          What is a ZEbRA? It might be easy to look at some of these Dangerous Animals and say, “That would never be me. I don’t have the authority to be a HiPPO and I’m too clued in to be a RHiNO.” And that may be true. But we can all be guilty of being ZEbRAs from time to time—yes, even the product managers and engineers among us. Sure, we theoretically understand the importance of having evidence to back up our opinions. But sometimes when we’re dealing in our areas of expertise, it can be tempting to skip over some of the validation process. Why are ZEbRAs dangerous? When ZEbRAs take control, you risk building products or making decisions that aren’t 
 validated (sound familiar?). You might luck out occasionally and still get things right. 
 But you could also lead the product in the wrong direction. Maybe you build things that your customers don’t...
Read more

Rhino

Image
                                                        What is a RHiNO? Often, people outside of the product team—especially those in sales and marketing—can be motivated by a high-value new opportunity such as the possibility of making a sale or landing 
 a particular customer. A RHiNO might say something like, “If we just had feature X, we’d be able to make this sale.” And while the RHiNO’s intentions are good, their approach can be myopic and disruptive. Why are RHiNOs dangerous? There are a few potential problems with giving in to a RHiNO’s requests. First, while they will often try to tell you that it’s simple, that’s rarely the case. Any new feature you build will take 
 on a life of its own. It can introduce complexities to your codebase, may require modifications to your product training, or present support issues. These unintende...
Read more