Halloween is this weekend, but there are probably some things that scare you worse than depictions of witches and ghouls. 

When things go wrong with a work project in a major way, there’s no other way to describe it than as a nightmare. The damage done to your weekend and evening schedule--or, in some cases, your pride--can be painful. Sometimes it's the result of a bad management choice, a simple human error, or a combination of factors that resulted an unwanted mess in which you found yourself. We can all relate to a good developer horror story. 

Here at Entando, we asked our team to share some of their worst work-related stories. We assumed that any horror stories would come from their time before joining our organization. ;) And they shared some doozies with us!

Here are 5 stories that just might send a chill up your spine.

Going the extra mile

I was 21 years old, my first engineering job. My boss came in and asked me to write the UX interface for a hardware controller for a police test vehicle. (I had also designed and built the hardware.) I was an electrical engineer, so my coding was not the greatest for UX design. But I thought it would be fun to write.

I spent 2 days writing it and I thought it was pretty good but that it needed another day to complete. After lunch, my boss came in and said, “Why are you working on that? I never told you to work on that!” And I said, “Uh, yes you did." But he stormed out of my office. Best first job ever!

Does anyone really know how to spell Schwarzenegger?

While an SA at Sun Microsystem, the governor of California wanted an auto-reply setup to his email address. The requirements: send a response within 20 seconds of receiving an email for up to 1.5 million people. 

That's the horror I guess.

I ended up setting up twin Sun Microsystems Enterprise 420R servers with 1 email server, with 1 email account (the governor’s). It worked and could handle the load. I thought it was a job well done.

The only problem is I spelled the governor’s name wrong in the email reply.

Change of plans

We had a death march project--lots of missing or late requirements, tons of overtime, and a difficult deployment environment. Several of us were on the final deployment meeting working until three in the morning to finish launching the new application on time on the night (or rather the morning) of the deadline. All that was left was the key stakeholder's approval to make the DNS change to make it live in production. 

We all left to get a few hours sleep and when we rolled back into the office at 9am we learned the launch had been delayed a month. No reasons. No explanation. And not much team morale either.

Checking all the boxes

I was troubleshooting a performance issue for a marquee customer. The issue was persistent and was preventing the application from going live. We ran all the tests we could think of. We reproduced their entire environment, added all the tracking tools, looked at packets on their network, looked at their load balancers, and we learned...nothing. The customer was threatening to cancel.

After two weeks of full days looking at code and network packets, we happened to open the XML definition of the tests. And at the bottom, they had selected “Emulate Slow Network Connections.” The tests were emulating what was basically a dial-up internet connection. We unchecked that checkbox and everything worked!

A simple business plan

This was back when I was in the sciences, but a good bit of my job was writing hardware interface software. My manager at the time was something of an inventor in the medical device field, and she came to me with her business plan. She said, “Step 1, you need to do X and then, Step 2, I'll figure out how to make a lot of money from it.” 

In this case, X was a science breakthrough that has still not happened over 20 years later. I would have received the Nobel Prize in physics if I had done it. When I realized that it wasn’t just A business plan but was THE business plan, I started looking for a new job--before her investors figured out the same thing.

Write a better story for your enterprise with Entando.

When release cycles take months instead of weeks, your business is left unable to deliver modern online experiences. Development and deployment bottlenecks slow your ability to make application updates, keeping you from iterating and innovating. And outdated or clunky UX keeps you from winning customers over and retaining them.

So that’s why we created a platform to help you get your ideas to market faster.

Entando is the leading micro frontend platform for building enterprise web apps on Kubernetes. We want to change the way enterprises think about building their apps, sites, and portals in order to innovate more quickly.

With Entando, you can:

• Leverage customized blueprints using the Entando Component Generator (built on JHipster) to quickly create micro frontends and assemble them into an app.
• Reuse UI/UX components across multiple projects via the Entando Component Repository, saving money and increasing development speed. 
• Scale apps quickly and effectively with Entando’s custom Kubernetes operator, automating the deployment of high availability, self-healing applications. 
• Centrally manage user roles with Entando Identity Management (built on Keycloak).
• Entando is open source with available enterprise support and services. 

Begin developing on the platform today, and get a quote to see how our team can help your enterprise build better apps, sites, and portals--faster.