Adopt Admiral Ackbar to Identify Software Development Pitfalls | by Ben “The Hosk” Hosking | September 2022

It’s the invisible traps that catch you


Developers set themselves traps, prevent themselves and get surprised when they enter the trap

When I hear the words “it’s a trap” which isn’t enough for my liking i hear these words spoken in sleazy twang of admiral ackbar from star wars – return to the jedi

When building software, you need a mini Admiral Ackbar sitting on your shoulder to keep you from falling into a trap.

The easiest traps to fall are the ones we set for ourselves (underestimating, overpromising, opening our mouths when we should shut them, writing code when we don’t need code, or writing the wrong code ).

If all developers were more like Admiral Ackbar, software development would be full of developers with massive fish heads that would help the team avoid invisible shields.

Admiral Ackbar is famous for being the first to call it a trap. This is exactly the type of developer you want on your development team. Unless he says it’s all a trap all the time, which would get boring.

The internet loves Ackbar, he has many memes, despite only having 14 lines in Return of the Jedi.

It’s a normal day for Ackbar in the rebel alliance, they have a pathetically small number of spaceships and are going to attack a massive planet sized space station (the death star) because they believe that shields will be down and the Death Star will be vulnerable.

I’ve worked on some tricky projects, but when you’re told you’re going to attack the Death Star, you hit up LinkedIn to read some of the tempting job postings in your inbox just in case.

As they’re about to attack the Death Star (think pre-draft meeting), someone called Lando tweets asking reasonable questions about whether the invisible shield is raised or lowered.

We need to get some kind of reading on this shield, up or down. Well, how could they confuse us if they don’t know if we’re coming. LANDO

At your project meeting, this is where a few Lando developers will ask a few questions about the requirements (or lack thereof) and who said it would take 20 developers six months to create software that only has a descriptive paragraph.

Lando’s mind is really spinning now and he’s giving worried looks to all the oblivious idiots on the ships that are about to fly into an invisible shield/wall.

Stop the attack! The shield is still up. LANDO

Finally, the management listens to the devs – I mean the rebel fleet listens to Lando and turns around (but in a cool way with a spaceship, not like a grandma on a bike)

“The Falcon and Red Squad fighters veer desperately to avoid the invisible wall.”

Then there are some nonsensical space talks about green bands and the MV-7 sustain section! It’s Ackbar who buys time because he knows he messed up a bit. Then they notice enemy ships, which leads Hercules Ackbar to deduce “It’s a trap!”

here is full discussion

Lando Calrissian: We need to be able to get some kind of reading on this shield, up or down.

Nien Nunb: [speaks in Sullustese]

Lando Calrissian: But how could they jam us if they don’t know… if we’re coming?

[over comlink]

Lando Calrissian: Stop the attack! The shield is still up!

Wedge Antilles: I’m not getting any readings. Are you sure?

Lando Calrissian: Come up! All trades, pull up!

Admiral Ackbar: Take evasive action! Green group, stay close to the MV-7 hold section!

My Calamari: Admiral! We have enemy ships in Sector 47!

Admiral Ackbar: It’s a trap!

Reading it over, it looks like Lando did the heavy lifting, but as all good devs know, it doesn’t matter who did the work and who gets the credit (e.g. not the devs), but that there finally had some credit to give.

Remarkably, how many long-term benefits people like us have gained from trying not to be stupid, instead of trying to be super smart. Charlie Munger

Many traps are set for developers and development teams who must remain vigilant to avoid venturing into them.

Software developers should be wise and write code well, some issues you should avoid rather than solving with code. The less code you write, the less code there is that causes problems for the development team.

Avoiding stupidity and putting the development team in a dangerous situation gives you more time and fewer problems in the future.

You are looking for invisible shield traps. Plausible sound strategies that seem correct from a distance. Things can pass the sniff test, but you have to lean closer to look at the details.

Presentations, words, emails, agendas get things approved/agreed. Most means of communication are not there to communicate but to confuse, mislead and prevent people from asking too many questions.

When you see nonsense words like strategic, progress, tactic, foundations and technical terms. These are used to dissuade people from asking difficult questions and reporting potential problems. Don’t fall into the trap.

Common pitfalls in software development are:

  • Underestimating Development
  • create code when business processes could be changed
  • Say yes to meetings you don’t need to be in
  • Don’t raise a problem with optimistic plans
  • Not preparing for things to go wrong
  • Ignored Risks
  • Requirements, information, access nearly complete or skipped

Software development is a losing game, the development teams that make the fewest mistakes will make the most progress.

You won’t have Admiral Ackbar on your project, so you have to make Admiral Ackbaring yourself. When people talk about requirements, plans, or anything else, you have to ask yourself the questions.

  • Where is the trap ?
  • How will this cause me problems?
  • If it went wrong, how would it go wrong?

Be on the lookout for traps that don’t look like traps. You must imagine Admiral Ackbar leaping up and shouting in a fishy voice – It’s a trap

A good example of preparation is when you deploy, imagine what would happen if certain services or processes went wrong. What would you do?

If you were to write down the issues in the future that caused the software development team big problems, what are they? and what damage have these problems caused?

what would i do – look for the traps

  • Development environment deleted → restore from source control
  • Lead developer gone → everything should be under source code control and documented
  • Service x is down → a specific error should appear

You can’t stop glitches, bugs, and glitches, but you can prepare for them and make sure they end in disaster. Technical disasters shouldn’t catch developers off guard

Software development is sneaky. He cradles you in his arms without you realizing that he has grabbed you and could knock you down at any moment.

Past experience is no protection against Ackbar’s invisible shields. That’s what I call The Turkey Developers and the Christmas Day Problem. You might have a big problem that you missed out of sheer bad luck – like not putting your code into source control or backing it up before production releases. It can be fine 99% of the time, but when it’s bad, it’s a disaster.

Having a mini Admiral Ackbar on your shoulder looking for traps helps you avoid or fix problems before they happen. Software development creates pitfalls that seem so real you don’t realize you’ve entered them.

Avoiding problems is a better and less stressful way to build software.

Wonder what Admiral Ackbar would do – SCREAM IT’S A TRAP

Comments are closed.