Rushing prototypes into integration testing means sharing the risk

The classic risky-development situation

In practice, this kind of situation is a classic in development work. Everyone goes through it with a heavy heart.

You have to run unit tests thoroughly before moving on to integration testing. Common sense. You have to evaluate a 3D-printed version before making the machined part. Common sense. Self-merging is forbidden. Common sense.

But everyone knows that development never goes entirely by the book.

To be clear about what kind of case leads to “things not going by the book,” it’s generally a situation where the schedule is tight. The causes vary — parts arriving late and squeezing the verification schedule after PCB assembly, staff unavailable because of conflicts with other projects and progress stalling, specs taking forever to settle so prototype work starts late, or the original plan simply being reckless to begin with. Either way, there isn’t enough time secured, and you’re forced into a choice:

“Do we push back the schedule? Or do we just go for it and move on to integration testing?”

That’s an extremely uncomfortable, critical situation. One that shouldn’t happen.

But anyone who flatly condemns this kind of situation as “insufficient planning” or “poor coordination” is probably a bit short on development experience. Or maybe they’ve only ever worked in very fortunate environments. I’m sure many developers are nodding along right now thinking “yeah, that’s how it goes.”

Especially at startups, there are plenty of situations where missing a single event — whether it’s an exhibition, a pitch to investors, or a demo for a partner — can directly tip the company over.

There’s a famous episode about the launch event for the Apple II, one of Apple’s early products: right up until the day itself, the odds that the prototype would actually boot properly were apparently worse than fifty-fifty. But they pulled off the demo that day, and that success carried them toward the future they have now — a major corporation fighting for the top spot in market capitalization.

But reality isn’t always a good story like Apple’s. Plenty of cases exist where rushing the schedule led to a brutal failure. In fact, that’s the more common outcome.

That’s why I said earlier that developers would nod along and say “yeah, that’s how it goes.”

If it’s a classic situation, let’s have a countermeasure

Not just for integration testing — here’s the key point to keep in mind whenever you’re pushing through something unreasonable that departs from the standard process.

Above all, tell the people around you and make sure they understand.

You might wonder what I mean by that, but this is the single point I think matters most.

Make sure people understand the risk

When you push through something unreasonable, there is naturally a chance of failure. Failing can easily delay the overall schedule even more than if you had honestly followed the original process and slid the schedule step by step. A bug overlooked because verification wasn’t thorough enough might only surface right when shipment is finally about to happen.

And this is a decision made with that risk in mind. This isn’t about pinning down whose call it was, like some blame game. The situation isn’t leisurely enough for that. It needs to be understood, clearly, across all the stakeholders, that “we” made the decision to hit the accelerator here.

Thinking “I said it once, so it must have gotten through” or “I wrote it in the documentation, so we’re fine” is dangerously naive. You need to communicate it again and again. Preferably out loud. You need to repeat it so many times that it sinks into people at a cellular level, to the point where the people listening almost start to feel like it was their own decision.

Why? Because the worst-case scenario is someone saying, “I never heard about that.”

Say, for example, that the development team decided in a meeting to go ahead with integration testing, and the schedule bottleneck was a demo for a key client at a sales visit. The development team lead naturally treats this as his own responsibility, but mentions it only briefly at a regular meeting between team leads. The sales team lead is present at that meeting, but comes away thinking only something like, “(Okay, well, we’re still on schedule, right?)”

Then on the day of the demo, a member of the development team tells a member of the sales team, “Feature A works, but Feature B doesn’t” — and that’s when things blow up. The sales team member says: “I never heard anything about that.” The development team member replies, “No, we talked about that risk within the dev team, and it should have been reported at the leads meeting.” The sales member fires back, “Are you serious? If I’d known that, I could have pushed the schedule back a week.” There’s no exchange more unproductive than “I told you / no you didn’t.” What matters isn’t who’s at fault — it’s making the demo succeed and landing the sale.

Another common pattern is someone saying, “I didn’t realize the risk was that serious.” Understanding naturally varies across departments, on any topic. That’s only natural, since expertise differs. But when it comes to risk, there needs to be a shared understanding across departments.

Generally, the people on the ground take risk most seriously, thinking through even the worst-case scenarios. But managers, since they leave things to the people on the ground, start to view things through somewhat more optimistic lenses. Cross a department boundary, and the view gets even more optimistic: “(Somehow it’ll work out in the end.)” By the time you get to an executive overseeing everything, in most cases they aren’t even exercising their own imagination — “Whatever you all reported to me is all there is.” And you can’t really blame them for that. People in higher positions have to keep many other matters and issues in mind and view everything from a bird’s-eye perspective.

I don’t believe a gap like this gets closed by a single meeting or a single report, and I’ve seen, many times, situations on the ground where a gap like this became the seed of a rift that could never be crossed later on. Many times. Yes — it’s an extremely typical mistake that keeps repeating itself over and over in all kinds of places.

The only way to resolve it is to communicate. Again and again, as persistently as it takes.

Originally published in Japanese at https://clazytech.com/2021/08/493/. Translated with LLM assistance and reviewed before publication.