Category: Just for fun

Tower anti-patterns

markri Leave a comment

Hopefully you find that the “spaghetti code” anti-pattern is something from the past (if not, you should do yourself a favour and find yourself another project 🙂 ). Does it mean hat our code is now perfect? And does it mean that it is so transparent that everyone instantly understands the motivation and its purpose behind each line? I’m not going to answer that (retorical) question. But I wondered; what are the new “bad practices”? How do they look like? So I gathered my experiences and trying to find and name them accordingly into some self declared tower anti-patterns.

Huge disclaimer: So I tried coming up with some new namings of the misfits I found and poured that into the so called “tower anti-patterns”. This is just for fun, I’m sure you can find a thing or two which don’t cover the title, or is even faulty logic on my side. For example, the anti-patterns are not only seen from a technical point of view, but also from organizational perspective.

I was glad I couldn’t find examples of total failures or laughable situations in my recent experience. But I could find some uncomfortable situations in code bases and its company surroundings that just felt wrong, they just aren’t fit for its purpose. That doesn’t mean the code itself was that bad, but the combination of project methodology, budget, code architecture and purpose just weren’t aligned. All these things need to be in balance. If not in balance it’s not a fit.

There are many possible situations of disbalance within the force. The big difference with “big ball of mud” / “spaghetti code” is that following anti-patterns are not neccesarily equal to total failure. It IS possible to recover from these (from a technical standpoint) or prevent even worse things happening. So here the tower anti-patterns:

tower of pisa

Tower of Pisa

The analogy to a software project is that it starts great but it eventually will be hard or risky to extend. The good news is that this is not all too bad; if you keep it small then it can still be great. Don’t extend too much, instead build a “tower” next to it. Think microservices.

Jenga tower

I borrowed this analogy from an ex colleague of mine, which he used during a business meeting with a customer. Just like the Jenga game, it’s matter of time until everything collapses due to a bad foundation. Every time someone touches the code the risk of breaking stuff increases. To recover from this is really hard, but it can be contained. Just don’t touch the code anymore. Put everything in an immutable container and leave it be. Don’t fix if it ain’t broken

Trump tower

Like a baboon with much noise this compares to a violent volatile development environment (keywords are; many stakeholders, large investments and tight deadlines). There is much money poured into these kind of prestige projects. This is also the seed for its decay because in such environment barely nothing can grow in a sustainable manner. Eventually it will show cracks and will go down because of stupid mistakes and distrust. If you’re in such a project you won’t be able to speak your mind, because there is probably too much baboonism. Although there might be parts which are quite ok, they tend to be not excelling. Once the shit hits the fan the baboons are suddenly gone. From technical point of view there might be some parts worth saving. When considering your own well-being; I strongly advice to just walk away before the baboon does. When that happens think twice who is left to blame for…

Tower of babel

This is about a monolithic software project that no-one fully understands. It has become so large that it’s hard to get a grasp of every component. Think enterprise applications after many years of development. Usually there are a few architects within the company that still know the entire landscape, but they will slowly become a single point of failure. It is not impossible to recover from this situation but it will take time. One needs to cut the application in pieces, create hard separations by implementing microservices. Then it will be easier to replace parts, and it is not neccessary to know all ins and outs of every component.

Code nostalgia with Quick Basic

markri Leave a comment

With my wife I was discussing the discipline of doing backups, in doing so I was thinking of how old my oldest file would be. How many years could I go back in time? I’m not talking about backup retention schemes but about my oldest creation, the oldest modification date. So exploring the crypts of dusty ARJ archives looking at the bits and pieces I stored, I found some old code of mine that was so dusty and old, it made me smile and filled me with a feeling of nostalgia. I wanted to share this code nostalgia with you.

Facts and stats

Last modification date: 18 december 1991 (previous century :-))
My age back then: 11 years
Platform: MS-DOS
Language: Quick Basic
Project: Programming the mastermind game
Status: buggy/but some parts work

The code

Surprised about the ramblings of my 11-year old self, I came to the idea of reviving the code. With some fiddling with the dosbox emulator it was suprisingly easy to make it work again! I put a recording at the end of this post. It’s somewhat magic to see 25 years old code working on current computer.

Useless for sure, it contains a bug concerning the black pins, but it doesn’t matter, I was happy that night 🙂

 

 

And the screen capture:

code nostalgia