Monthly Archives: April 2019

Coding Horrors: Sometimes They Come Back

“Within its gates I heard the sound
Of winds in cypress caverns caught
Of huddling trees that moaned, and sought
To whisper what their roots had found.”
― George Sterling, A Dream of Fear

This month’s post is a guest post by Giles Payne, a teammate from a project at Giesecke & Devrient Mobile Security almost two decades ago. At the time, we were trying to teach good coding practices by distributing so-called “Coding Horrors”, bad code examples, that showed what not to do. The other day, Giles sent me such a “Coding Horror” that he came across recently. I couldn’t help but talk him into blogging about it. Giles, take it away!

Thank you, Ralf! Let’s dive right into the code — for fun please take a minute to try and work out what this little piece of Java is doing.

(5 minute pause for head scratching.)

Were you able to work it out? No, I didn’t think so. So what is going on?

This code comes from a kind of simple browser-like application that needs to handle a stack of displayed pages. In some cases it will manage a history of the pages, in other cases it doesn’t care about the history — hence the “USE_PAGE_HISTORY” descriptor.

But what exactly is it doing? Well, what this particular code does is change the meaning of the equals comparator for PageIds to always return true when USE_PAGE_HISTORY is false. (Face palm.)

In an attempt to pinpoint exactly what is so horrendous about this I’ve written up a few basic “programming principles” that I feel have been grievously violated here.

Principle #1: Don’t be language snob.

If you’re programming Java, then program Java, if you’re programming Visual Basic, then program Visual Basic. The person that wrote this code was obviously heavily into functional programming languages. So totally into functional programming languages, that the thought of writing code in a non-functional programming language like Java drove him or her to distraction — or more exactly to use the “Functional Java” library. “Functional Java” is basically an attempt to turn Java into a functional programming language, which it doesn’t really manage to do. What it does do is turn your code into cryptic, impenetrable gobbledygook like this.

Principle #2: Don’t bury important logic deep in non-obvious abstractions.

The usePageHistory moniker is pretty easy to understand. If I see code like

it’s pretty easy to follow. If I had lots of places with the same if-else logic, I might separate the logic into two classes like PageStackBasic and PageStackWithHistory. Hiding the logic like whether you’re using history or not inside the equals comparison operator is a recipe for disaster because nobody is ever going to think of looking there (see next principle).

Principle #3: Don’t override standard operators in non-standard ways.

Some languages like C++ let you override arithmetic/boolean operators — others don’t. There is a lot of debate among language designers about whether allowing operator overriding is a good thing or a bad thing. On the plus side there are some very cool things you can do, for example if you have a class representing matrices then you can override the * operator to do matrix multiplication. On the minus side, they let you write stuff like this. While this code probably works now — it’s the kind of code that probably will stop working one day and when it does, it will take out an entire country’s air-traffic control system*. While it probably seemed like a clever or elegant piece of code to the person that wrote it — it’s a maintenance programmer’s nightmare.

Principle #3 is actually picked up on in the highly amusing “How to write unmaintainable code“. It’s basically a back-to-front version of “Coding Horrors” where bad coding practices are encouraged as means to achieving a job for live. (Oh my gosh, this is a Fake Surgeon’s gold mine! — Ralf’s note.)

________________________________

*) Relax — this code is not part of an air-traffic control system. My point was simply that when bad code like this blows up, the impact usually tends to be massive. ↩

People Patterns In Software Development: The Fake Surgeon

“I just trust my intuition taking into account the psychology of things. Therefore, I am not persuaded by facts, but by behaviors.”
― Maria Karvouni

In his classic book on software engineering, The Mythical Man-Month, Fred Brooks presents a radically different approach to organizing development teams, which he coined the “Surgical Team.” His idea is based upon three key insights:

1. Great software developers are easily 10 times more productive than average developers.
2. Conceptual integrity is the key to the success of every software product, especially large software products.
3. The bigger the team, the more communication paths are required, which is detrimental to conceptual integrity.

Consequently, according to Brooks, a software team should consist of a single super-programmer (the “surgeon”) accompanied by nine “assistants,” give or take. The surgeon is not only the boss of the team, but he also does the main work; that is, thinking and programming, all for the sake of minimal communication and conceptual integrity. The assistants have clearly defined roles, all aimed at making the surgeon’s life easier and boosting his productivity: for example, they support him as backup programmer, editor, tester, and secretary.

To grade A developers, this approach looks quite appealing, as they finally get the resources, recognition, and status that they crave so much, while at the same time still being allowed to do what they love to do most: programming.

Alas, for various reasons the whole idea was stillborn (boo-hoo!), but that’s not what I want to focus on today. For the rest of our discussion, you just have to bear in mind these facts about Brooks’ analogy:

1. The surgeon is a talented and experienced developer.
2. The surgeon is the boss and has the company’s official mandate.
3. The assistants respect the surgeon and fully accept their roles as subordinates.

A Fake Surgeon, by contrast, is a wannabe surgeon—a surgeon that has no official mandate and his imagined assistants neither accept him nor their ascribed roles.

Early in my career, I was part of a fake surgical team. The Fake Surgeon was very prolific, worked ridiculous hours, and never went for lunch. Why? Because he wanted to make himself indispensable by keeping a massive head start on the rest of the team.

Sometimes, he would leave the office late at night for only a couple of hours, to take a quick nap and a shower. When the other team members arrived in the morning, they couldn’t believe their eyes: so much had changed overnight! They really didn’t know how or where to contribute. Instead of filling them in, the Fake Surgeon’s solution was to assign his “assistants” only non-critical, menial work because, according to him, he was way too busy to explain what he did during last night’s blaze of glory. This tactic ensured that he remained the keeper of the crown jewels. Managers, sales, customers—they only talked to him, because he was the authoritative source of everything, thus isolating the rest of the team even more.

He put up such an act, always looking so busy and stressed, that you didn’t dare disturb him. If you finally got up the courage, he’d only give you short, superficial, sometimes even misleading replies.

Reading his code was far from easy—it left you puzzled and gave rise to many questions; questions, that you were too afraid to ask. Obviously, mysterious, unreadable code was yet another element of his cunning plan: job security by code obscurity.

APPEARANCE

Regarding the choice of clothing, a Fake Surgeon is pretty average, at least clothes do not define him. By and large, he doesn’t spend much time on looks; instead, he invests his time speeding ahead of everyone else. It’s highly likely that he appears rushed, always hustling about the office, never socializing over coffee, just swiftly refilling his mug before running back to his keyboard.

PERSONALITY TRAITS

Most likely, the reasons for a Fake Surgeon’s behavior are deeply rooted in his low self-esteem and fragile ego. Deep down inside, he’s aware of his limited skills and is in constant fear of losing his job. To compensate for his insecurity, he tries to establish a regime of control, keep as much of his knowledge to himself, and make sure that his enigmatic code can only be understood by him and nobody else. A self-confident programmer, by contrast, knows that he’s indispensable because he shares information and writes clean code that can be extended by others.

Of course, such a pathological type of developer can’t thrive all by himself. Every Fake Surgeon forms an unhealthy symbiosis with an extremely weak manager who condones such egoistic behavior. In most instances, the Fake Surgeon’s boss doesn’t see through the Fake Surgeon’s ulterior motives and might even praise the Fake Surgeon for his unusual commitment. After all, the Fake Surgeon takes care of everything and thus gives the boss plenty of time to work on his own career.

What ends up happening, in almost all cases, is that the Fake Surgeon sooner or later takes advantage of his distinguished position and extorts the company by asking for a sizable pay raise. Usually, the company gives in, must give in, because they can’t afford to lose such an important person. What these companies fail to recognize is that they already lost him, anyway. Fake Surgeons are sly and anticipate that once they’ve made such a move, their days might be numbered. Hence, they use this promotion just for negotiation purposes and try to land an even better paid job with a competing company. A company, where the Fake Surgeon can rightly claim, “In my previous job, I did everything by myself” and where nobody knows his selfish, dirty little secret. Depending on whether his need for security and power are ultimately met at the new job, he might settle down and mellow out; if not, he might establish yet another cycle of abuse.

RATING

According to the Q²S² framework, a Fake Surgeon’s rating is 5/2/1/1.

TOOLING

A Fake Surgeon likes tools, especially tools that give him a strategic advantage over others. Most likely, some of the tools that he (or the team) employs were created by himself, such that he’s the only person who can operate and extend them. He also fancies rarely used libraries and programming languages and exerts quite a significant amount of effort in mastering them. To a Fake Surgeon, that’s time wisely invested, as it allows him to race ahead on steroids while the rest of the team is limping along.

CONCLUSION

Information hiding is a sound and proven software design principle but it doesn’t carry over to developers working on a team. A Fake Surgeon is the opposite of a team player—he’s a ball hog. He’s a charlatan that dupes everyone into believing that he’s a real surgeon. All he has in mind, however, is advancing his career at the expense of others, often putting the fate of whole companies at risk. He’s such a nuisance to work with that often valuable team members (who never got a chance to prove themselves) leave the toxic environment he created.

A strong manager is required to prevent a company from being taken hostage by such an individual. A strong manager wouldn’t fall prey to a Fake Surgeon’s ensnarement. Instead, he will make knowledge sharing a priority and ensure that everyone leaves the office on time. Managers, beware red flags: If somebody works excessive overtime, tell this person immediately that they should rather use their time to enable others to contribute. This way, the person’s time will yield a high return on investment and reduce the overall risk for the project. If he doesn’t understand, ask him to seek his luck elsewhere. Don’t shed any tears over this person: the only thing that you lost is a problem.

Bug Hunting Adventures #13: Prime Sums (Solution)

The challenge suffers from what I call a “chain of blunders”, where one blunder leads to another. Here are the exact details, in the traditional format.

The first who got close to the true nature of this bug was reader Shlomo who commented directly on the post, but I held back his comment in order not to spoil the fun for others. (Unfortunately, I couldn’t tell him, because he used a bogus email address—boo!). Christian Hujer, hacker extraordinaire, gave the most precise and extensive account on LinkedIn. While many found the blunder in the Makefile (Joe Nelson was the first), it was apparently such a good smokescreen that many people didn’t look any further. To me, the root blunder that started the chain of blunders is in the C language itself, which should have never allowed implicit zero-initialization of constants in the first place (which was corrected in C++).

Some believed that the preincrement of the loop-counter was the culprit as it would skip the first prime, but that’s not the case. The expression after the second semicolon gets evaluated always at the end of the loop body:

is equivalent to

Substitute ++i or i++ for <e> — there’s no difference!

On a general note, guys, please register by entering your email address in the top right corner to ensure that you will get automatic notifications for new posts as soon as they’re published. I also (usually) announce new posts on LinkedIn, but mostly hours if not days later. Nevertheless, connecting with me on LinkedIn is always a good idea and highly encouraged. Your subscriptions, likes, praise, and criticism keep me motivated to carry on, so don’t hold back!