Skipping straight to integration testing is a common pitfall, not incompetence

Common Pitfalls in Risky Development

Honestly, situations like this are a common pitfall in development. Everyone runs into it, and everyone feels the pain of it.

Run unit tests thoroughly before moving to integration testing. That’s common sense. Evaluate with a 3D print before machining the part. That’s common sense. Self-merging is forbidden. That’s common sense.

But everyone knows development doesn’t always go according to the template.

To be clear about what kind of case leads to “things not going according to the template,” 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 pulled away by other projects and progress stalling, specs taking forever to settle so prototyping starts late, or the original plan being reckless from the start. Either way, there isn’t enough time, and you’re forced into a choice:

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

This is an extremely troubling, critical situation. It’s a situation that should never happen.

But anyone who reflexively condemns this kind of situation as “lack of planning” or “insufficient coordination” probably just lacks development experience. Or maybe they’ve only ever worked in very fortunate environments. I’m sure many developers are nodding along, thinking “yeah, this is a common pitfall.”

Especially at startups, missing a single event — a trade show, a pitch to investors, a demo for a partner — can directly send the company faltering.

There’s a famous episode about the launch event for Apple’s early product, the Apple II. Right up until the day of the event, the odds of the prototype actually booting properly were apparently less than fifty-fifty. But they pulled off the demo that day and connected that moment to the future that followed — the future in which Apple is now one of the biggest companies vying for the top market cap.

But reality doesn’t always give us good examples like Apple’s. Plenty of cases exist where rushing the schedule led to a painful failure. In fact, those cases are more common.

That’s why I said earlier that developers would nod along, thinking “yeah, this is a common pitfall.”

If it’s a common pitfall, let’s do something about it

Not limited to integration testing alone, here’s the important point to keep in mind when pushing through something reckless that deviates from the template.

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

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

Making people understand the risk

When you push through something reckless, there’s naturally a chance of failure. That failure could end up delaying the overall schedule even more than if you had simply followed the original process and slid the schedule step by step. A bug overlooked due to insufficient verification might not surface until it’s finally time to ship.

As for the fact that this decision was made with that risk in mind: this isn’t about assigning blame over whose decision it was. It’s not a situation leisurely enough for that. Every stakeholder needs to properly understand 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 far too naive. You need to communicate it again and again. Preferably out loud. Keep telling people, over and over, until it sinks in at the cellular level — to the point where the person listening starts to feel like it was “their own decision.”

Why does that matter? The worst-case scenario is being told, “I never heard about that.”

Say the development team decides in a meeting to go ahead with integration testing, and the bottleneck on the schedule is a demo for a major client at a sales meeting. The development team leader naturally treats this decision as their own responsibility, but mentions it only briefly at a regular meeting between team leaders. The sales team leader attends that meeting and comes away with something like, “(Okay, so basically, we’re sticking to the schedule, right?)”

Then, on the day of the demo, a developer tells someone from sales, “Feature A works, but Feature B doesn’t,” and everything erupts. The sales team member says, “I never heard about that.” The developer responds, “No, that risk was discussed within the development team, and it should have been reported at the leaders’ meeting.” The sales member fires back, “Are you serious? If I’d known, I could have pushed the schedule back a week,” and so on. There’s nothing more unproductive than a “he said, she said” argument. What matters isn’t who’s at fault — it’s succeeding at the demo and landing the deal.

Another common pattern is being told, “I didn’t realize the risk was that serious.” Whenever departments differ, understanding naturally becomes uneven. 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 front lines take risk the most seriously, thinking through even the worst-case scenarios. But once you become a manager, delegating to the front lines pushes you toward a somewhat more optimistic view. Cross departments, and people grow even more optimistic. “(Someone will sort it out in the end.)” Once you reach the level of an executive overseeing everything, in most cases they don’t even exercise their own imagination — they think, “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 think about many other projects and issues at once, viewing everything from a bird’s-eye perspective.

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

The only way to resolve it is to keep communicating. Over and over, as persistently as it takes.

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