Bad Code in Production (2020)

Complex Unnecessary Steps

I saw an app that consumes a stream of data and feeds it into many steps. It is even doing it back and forth.

Just because other apps use the same step. That does not mean you have to. I removed all the steps, but one. The app becomes faster, less code, and less bugs. No behavior changed.

I suspect the programmer uses a boilerplate or copies another project without understanding all the moving parts.

Using A Drill Without Reading A Manual

I find an app that parses a JSON text using a third-party library and then converts it into an object. Adding additional complexity without knowing that the library support accessing the object directly.

There are other interesting cases that I found. Such as not knowing what argument the function receives and just throwing anything into it os.getenv("KEY", os.getenv("KEY")). The author does not know that the second the parameter is for the default value.

Also, a case where using else everywhere in try-except-else. Even if it does not need. And the author that uses the boilerplate as-is. I found a service that returns 401 for all the error responses.

Another funny story is that I found a requirements.txt that contains all the output of pip freeze. Yes, it is huge and unnecessary.

Hardcoded Indexes

It is all fine, the unit tests are passed. The app sits well in production for a month, until one day chaos happens.

You will never know if your test covered all the possibilities of the real world.

Out of nowhere, I also found an app that hardcoded the database ID. wow, amazing!.

Conclusion

Bad codes are the siblings of bad reviews, and bad reviews are the sibling of bad managers.

If you can push mining code to production without anyone noticing. It is a horrible sign of a bad review process.

A programmer is a human and humans always took the easiest and laziest way possible. Sometimes in a bad term. It all can be avoided with a good system in the working environment.