A Tragic Incident of Swissair Flight 111

Swissair Flight 111 was a tragic incident that occurred on September 2, 1998.

The flight was en route from New York City to Geneva when it encountered smoke in the cockpit.

The pilots first declared ‘Pan Pan’, then ‘Mayday’, and sought to divert to the nearest suitable airport.

Unfortunately, the situation worsened, leading to the crash into the Atlantic Ocean near Peggy’s Cove, Nova Scotia, Canada.

Regrettably, all 229 individuals on board lost their lives in the accident. The majority of them were UN executives.

The Reason Behind 90s Worst Aviation Incident

The subsequent investigation revealed that a fire, likely caused by faulty wiring in the aircraft’s entertainment system, played a central role in the tragedy.

The fire spread quickly, leaving the crew helpless, and ultimately resulted in the aircraft losing control before crashing into the ocean.

Not only the fire, but another major culprit was the SOP which Swissair pilots were supposed to follow in the case of fire with an unknown source.

SOP asked them to dump the fuel first, rather than giving all priority to landing the aircraft as soon as possible. Because of this, they wasted crucial time dumping the fuel.

The Over Engineering that Led to Crash

Swissair was one of the few airlines that tried implementing an in-flight entertainment system and on-board internet connectivity.

However, aircraft of that era hadn’t been designed and developed for it.

Swissair knew about the in-flight entertainment system overheating problems for months.

In fact, some airlines even skipped installing it because of its power drain.

But Swissair went ahead, and now we’re all seeing the consequences.

But What’s the Real Meaning of Over Engineering in Software Product Development?

In simple terms – code or design that solves problems you don’t have.

That’s over engineering in the true sense.

And this classic meme shows how far a software product can stray from real user needs.

Why Do People Over Engineer Software Products?

Nobody does it with bad intentions.

It happens because we try to anticipate the future and be ready for the unknown.

And here are some reasons behind over engineering.

Source

What Are the Consequences of Over Engineering in Software Product Development?

You’ve probably got an idea by now that over engineering isn’t right for your product.

Let’s look at the consequences of over engineering that can break your product far into the future.

• Increased development time and cost
• Maintenance challenges
• Reduces performance
• Scalability issues
• Poor user experience

• Increased probability of bugs and errors
• Wasted resources
• Failure to meet user needs
• Risk of project failure
• A greater technical debt

How to Not Over Engineer Your Software Product?

The best way to prevent over engineering is to turn your engineers into true product engineers.

This is what we have done here at Azilen.

And that’s why we call them PROEngineers.

Apart from that, here is how you can end the dilemma of over engineering your software product.

Yup. They are both trying to write “return a==0;” but the overengineering mindset is stronger. 😂 https://t.co/EE4BBkt4J1

— Nilo Stolte, PhD 🍁⚙️ (@nilostolte) December 14, 2023

“You aren’t gonna need it” – is a principle that states a programmer should not add functionality until deemed necessary.

It works best when you pair it up with several other practices, such as continuous refactoring, continuous automated unit testing, and continuous integration.

The term KISS, “Keep it simple stupid”, refers to the fact that simple systems are easier to repair, evolve and maintain.

That means simplicity is your superhero in coding.

Your codebase should be like a well-organized toolbox, with each tool serving a specific purpose.

When you’re chasing simplicity, think about the “worse is better”.

This concept suggests that a minimalistic, simple solution that is easy to understand and implement may be more effective than a technically superior but complex alternative.

Crystal-clear understanding, that’s the foundation of successful product development.

Take the time to engage stakeholders, ask questions, and ensure everyone is on the same page – about what aligns with goals and what to avoid.

Change in requirements? Repeat the cycle.

Ever heard of MVP? It’s not just a sports term; it stands for Minimum Viable Product.

Think of it as the ‘core’ version of your project.

Get the essentials down first, and then you can evolve it later as per the requirements.

Keep Tech Choices Real. Tech stack decisions can make or break your software product.

Choose tools that actually make sense for your project size and needs.

And avoid using new libraries or frameworks just because they’re trending.

Break down your code into Lego-like modules – nice, clean, and easy to replace if needed.

And avoid connecting everything like a game of Jenga.

Because it might stand tall at first, but one wrong move and it all comes crashing down.

No one likes a clunky, outdated codebase – not even your code!

Regular code reviews and refactoring sessions are like spring cleaning for your codebase.

It eliminates redundancy, simplifies complex structures, and ensures that your code remains clean and maintainable.

Don’t waste time fixing things that aren’t broken – that’s the thumb rule.

Instead, focus on solving immediate problems and optimize only when performance becomes a genuine concern.

Because premature optimization can lead to an overcomplicated solution.

A user interface is like a joke. If you have to explain it, it’s a bad design.

Thus, your design choices should prioritize user-centric interfaces, consistent patterns, and responsive layouts.

Overall, it’s all about finding that sweet spot between a good-looking design and practical user experience – no need for fancy stuff that could overcomplicate things!