Likely Normal

If you’re like me, you’ve at least been tangentially involved in one or two IT projects that relied more on hope than a solid plan. Such projects operate off the official methodology of “We’ll figure it out later” and “That sounds like a problem for Future Us (who, spoiler alert, hate us).” These projects start with boundless optimism, like a toddler stacking blocks way too high, and end with that same toddler screaming why as it all collapses.

The hallmarks of hope-driven development?

1. The “It Probably Scales” Plan – Your MVP is held together by chewing gum and one overworked intern’s Python script. “What if we get a million users?” you ask. “We’ll cross that bridge!” they say, as if bridges aren’t notoriously flammable.
2. The assumption that no one will actually check the docs – The entire project hinges on zero people reading the fine print. “Eh, the API probably won’t change,” you mutter, as the third breaking update this week bricks your entire workflow.
3. The “Feels Right” Architecture – No blueprints, no testing, just vibes. “I think this microservice talks to that database? Maybe?” Meanwhile, the database hasn’t responded in days, and you’re too scared to check why.
4. The mindset that it can be fixed in production – The IT version of “I’ll definitely start exercising tomorrow.” Spoiler: Production is not your personal gym.
5. The fantasy that someone else will document it – The code is self-documenting (read: only the original dev understands it, and they quit last Tuesday).