Do you know these Software Engineering Terms?

I recently saw this reel by tiffintech and I went on a ‘Google Ride’ searching for some more funny terms in Software Engineering

Software engineering is a complex field with its own language. If you’re new to the field, or even if you’ve been around for a while, there are terms that you may not be familiar with. In this blog post, we will explore some of these terms and what they mean. 

Will they help you impress an interviewer? Probably not! 

Ostrich Algorithm

So, what exactly is the ostrich algorithm? It’s a strategy that can be used when dealing with errors or other problems in your code. It is a strategy of ignoring potential problems on the basis that they may be exceedingly rare. Essentially, it involves ignoring the problem since it might be more cost-effective to leave the problem as it is as compared to spending time/error trying to solve it.

to stick one’s head in the sand and pretend there is no problem

Of course, this isn’t an ideal solution, but it can sometimes be helpful if you’re in a pinch. It can be used to solve deadlocks in concurrent programming.

Reference

Yoda Conditions

Yoda Conditions are a style of coding where the programmer writes conditional statements in reverse or in a non-traditional way. For example, instead of writing:

if (x == 5) {
   // do something
}

They would write:

if (5 == x) {
  // do something
}

Yoda says “Become powerful you have, the dark side in you I sense.”

If you are interested, there is actually an English to Yoda Translator

The thinking behind this is that it’s less likely for a programmer to make a mistake and write x = 5 by accident, which would cause an error. While this may seem like a small thing, it can actually help to prevent a lot of bugs in your code.

So next time you’re reading some software engineering code and you see an if statement written in reverse, you’ll know that isn’t incorrect and the programmer may just be a star wars fan.

Reference

Status 418 I’m a teapot

The term “Status 418 I’m a teapot” is derived from the HTTP status code 418, which is defined as “I’m a teapot”. The code was originally meant to indicate that the server was a teapot, but it has been repurposed to indicate that the client is attempting to brew coffee with a teapot.

In simpler words, it is used to describe a situation where the client is trying to perform an action that is not possible. For example, if you try to brew coffee in a teapot, it will not work because the pot is not designed for that purpose. Similarly, if you try to do something that is not possible with a piece of software, it will also fail.

I’m a teapot, I can not brew coffee

The term “I’m a teapot” can be used in both positive and negative situations. If you are trying to do something and you know it’s not possible, you can use the term to describe your situation. On the other hand, if someone else tries to do something that’s not possible and they succeed, you can use the term to describe their accomplishment.

In either case, the term “I’m a teapot” is a way of describing a situation where someone is trying to do something that cannot be done.

Reference

Bugs

Heisenbug

Heisenbug is a term used to describe a software bug that disappears or changes behavior when an attempt is made to study or debug it. The name “heisenbug” is a pun on the Heisenberg Uncertainty Principle.

Reference

Hindenbug

A bug with catastrophic behavior. Think something along the scale of your entire database being wiped off. 

If you manually execute a SQL Delete statement without a where clause, it is more of a mistake than a bug. However, if you write a function to do the above, now that sounds like a Hindenbug.

Reference

The Gangnam Style Bug

When Psy release Gangnam style, he was about to literally break Youtube. Youtube initially stored its view count as a 32-bit number, i.e 2,147,483,647 views but Psy had different plans. Although Youtube did update its code before the 2,147,483,648th viewer saw a weird number of views, this deserves to be on the list of funny terms.

Youtube decided to move to a 64-bit counter so they are probably safe for a few more years. In case you are wondering, that's Nine Quintillion Views Lol.

Reference

Type of Code

Jenga Code

Jenga Code is a term used to describe a style of programming that results in the whole thing collapsing when you touch a single block of code. Named after the game where players try to remove wooden blocks from a tower without them falling down.

If you ever get a feeling that you don’t know what that line/piece of code does but removing it breaks everything down, well you might be working with some Jenga Code.

Reference

Spaghetti Code

 This term is used to describe code that is messy and difficult to read. It’s often the result of bad coding practices or a rushed development process.

If you’re working on a project with spaghetti code, it can be tough to make sense of it all. But with a little patience and perseverance, you should be able to untangle the mess and get things back on track.

Hydra Code

A little backstory about Hydra. 

Hydra was the offspring of Typhon and Echidna, the father and mother of all monsters respectively. Hydra’s lair was the lake of Lerna, which was claimed to be the entrance to the UnderWorld. Heracles’ second of the set of 12 labors was to slay the Lernaean Hydra. Hydra had a regeneration feature: for every head chopped off, Hydra would regrow two heads.

One head off, two heads Grow!

Heracles eventually managed to cut off all of Hydra’s heads with assistance from Iolaus.

Hydra Code is code that simply can not be fixed. For every new “fix”, two new bugs get introduced. Your best bet would be to rewrite the code.

Reference

Magic Code

Magic Code is Code that is usually taken verbatim from websites like StackOverflow. Although it might solve your problem, you don’t know how it works or why it works. It magically solves your problem.

Common Law Feature

A bug in the application that has existed so long that it is now part of the expected functionality, i.e it is a feature

It’s not a bug, it’s a feature

Reference

Pokemon Exception Handling 

If you have watched Pokemon, you must be familiar with it’s catch-phrase

Gotta Catch ’Em All

try:
    // Some Code
except Exception as Pokemon:
    // print("Catching all Pokemons", Pokemon)

Ash Ketchum might have never managed to catch all the Pokemons, but you can!

Reference

Yak Shaving

In software engineering, yak shaving is the term for when you have to do a bunch of small tasks in order to complete a bigger task. It is a task, that leads you to perform another related task, that leads you to perform yet another related task, and so on, and so on — all distracting you from your original goal. This is also sometimes called “going down the rabbit hole.”

Yak shaving usually happens when you’re trying to do something that depends on something else that isn’t ready yet. For example, if you’re trying to deploy a new feature to your website but your database isn’t migrated yet, you might have to migrate the database first. Or if you’re trying to write a unit test but you can’t because one of the classes doesn’t have an interface yet, you might have to write the interface first.

Yak shaving can be frustrating because it feels like you’re not making any progress on the main task — you’re just doing a bunch of busy work. But it’s important to remember that every task you complete brings you closer to your goal, and eventually you’ll get there.

Reference

Monkey Patch

Monkey patching is a technique used in software engineering to make changes to a program or library without changing the original source code. Monkey patches are typically used to add features or fix bugs in a program without waiting for the official release of a new version.

Monkey patching can be dangerous because it can lead to code that is difficult to maintain and debug. When doing monkey patching, it is important to be aware of the potential side effects of your changes.

Reference

Faith-based programming

When you try running the same piece of code again with hopes that the error just gets fixed magically. 

Reference

Hi-driven development

For most languages, there are a lot of debuggers at your disposal. You can add breakpoints and do a lot more to make it easier to debug a problem. However, a lot of programmers do not use Debuggers. What we do is, we add random print or console.log statements. If you see a statement like the below randomly in a function, there is a good chance the developer was debugging by practicing Hi-driven development

console.log(`HI.... ${varValue}`)

Most of us have our own version of Hi , personally, I use Yooo and a bunch of -x-x-x-x-x-x-x-

Reference

Conclusion

Let me know if you know of any other such terms in Software Engineering.

Want to Connect?

Find me on LinkedIn: https://www.linkedin.com/in/rahulbanerjee2699/

Originally Posted on https://www.realpythonproject.com/do-you-know-these-software-engineering-terms/