Software Development Requires Failing Faster

If code can’t be perfect, at least be first to break it

5 min readMar 30

My computer science degree lied to me, perfect code isn’t real. All those damn 200 line coding assignments I sweated out were all for nothing. Jokes aside, it’s weird for a profession which requires absolute correctness, we overlook the flawed human element of it frequently.

Today, I make a brave stand to discuss our filthy shortcomings. Nobody should purposely fail, but the systems should be setup to catch errors faster.

Let me explain.

Pass/Fail

Programming contains more failures than successes, but that one success is unbelievably relieving. This phenomena is so wild because many developers forget all the failures when planning future work. Talk about a vicious cyclical feedback loop.

Now, what is the first check for failures, assuming it’s a compiled language and no lazy evaluations are done for sanity sake. Think about the simplest check done on code.

Drum roll please, syntax errors.

Immediately the compiler screams, red text pops out of all angles, and life sucks for about 10 seconds before realizing the mistake. Maybe red squiggly lines exist on a fancy IDE. This, is the first check to ensure the code is working as expected.

On the flipside, the last check is running the code live AKA production. This is the real deal, if it breaks here, you dun goofed.

Last thing anyone wants to discover is a syntax error in production, hence why at minimum code is compiled or interpreted before being pushed out. As ridiculous as that statement is, it leads to the bigger picture of catching all possible avenues for a mistake to occur before going live. At no point will anyone catch everything for a single project, but anyone can do better to catch these errors.