What is a ‘Code Monster’?

Software Becomes a ‘Code Monster’ One IF at a Time.

Definition

A Code Monster is a metaphor for a piece of code that has grown uncontrollably due to repeated, unchecked additions of conditional logic, such as IF statements. It represents a class, method, or system that has become overly complex, fragile, and difficult to maintain or extend. Code Monsters are a common problem in software development, and they can have serious consequences for the quality, performance, and reliability of a software system. By defusing the IF Strategy and adopting more effective design techniques, developers can prevent the creation of Code Monsters and build software that is flexible, changeable, and easily testable.

Key Characteristics of a Code Monster:

  1. Bloated Size:
    A single class or method becomes disproportionately large, often due to the accumulation of conditionals and branching logic.
  2. Decreased Readability:
    The code becomes hard to understand, even for the original author, due to nested or duplicated IFs and inconsistent logic.
  3. Fragility:
    Adding or modifying behavior becomes risky, as changes in one part of the monster can unexpectedly break others.
  4. Increased Cost of Change:
    Every new feature or bug fix takes progressively longer because the monster’s complexity makes analysis and testing more time-consuming.
  5. Headache-Inducing Debugging:
    Developers waste countless hours identifying and fixing issues in the convoluted logic of the monster.

Origins of the Code Monster:

The Code Monster is born when developers repeatedly apply the IF Strategy—using IF statements to handle growth, change, or complexity without considering alternative design patterns. Over time, this approach compounds, leading to unmanageable code.

Lot of developers apply the "IF Strategy" to deal with growth, change and complexity:

	 IF ( new condition) { new code }

Unfortunately, by doing that regularly, they increase the complexity of their software system. As a consequence, the next changes will cost more and more!

The goal of the Anti-IF Programming is to raise awareness of the risks of applying the "IF Strategy" and to draw attention to the importance of replacing it with other design techniques, more effective to deal with growth, change and complexity. Defusing the "IF Strategy" enables developers to get a code that is flexible, changeable and easily testable. This will help to avoid a lot of headaches and weekends spent debugging!

Here's a little story...

...about a software developer working in a company who was building up a nice platform. One day the boss calls the developer on the phone and says: "There’s a new task I need you to do for a really important client, and it must be done by the end of the day. All that’s needed," the boss continues "is to add a small piece of functionality to that class method you’ve been working on... it shouldn’t be too complex..."

The days go by...

and that small class, edit by edit, grows into a small code monster: the more you feed it with IFs, the bigger it grows!

Do you think it’s just a fairy tale?

Well, it’s not!

What follows below is a single class method taken from real code that is live on a server somewhere on the Internet right now. And this is just a "baby monster". The more you feed it, the bigger it grows!

The Code Monster

                	calculateWageFor(Person aPerson) {
                		...
                IF=>	IF(aPerson.type == Person.EMPLOYEE) {
                            ordinaryHourlyWage = 15;
                            overtimeHourlyWage = 20;
                IF=>		IF(aPerson.status == Person.PARENTALLEAVE) {
                                ordinaryHourlyWage= ordinaryHourlyWage * .70; // 70%
                IF=>			IF(aPerson.daysOffLeft() > 10) {
                                    ordinaryHourlyWage = ordinaryHourlyWage * 0.9; // 90%
                                }
                            }
                            salary = aPerson.ordinaryWorkHours * 
                                    ordinaryHourlyWage +	
                                    aPerson.overtimeWorkHours * 
                                    overtimeHourlyWage;
                        }
                IF=>	IF(person.type == Person.MANAGER) {
                            fixedWage = 3000;
                            monthlyBonus = lastYearsProfit  * .10 / 12; // 10% monthly
                IF=>		IF(aPerson.status == Person.PARENTALLEAVE) {
                                monthlyBonus= monthlyBonus * .60; // 70%
                IF=>			IF(aPerson.daysOffLeft() > 10) {
                                    fixedWage = fixedWage * 1; // 90%
                                    monthlyBonus= monthlyBonus * 1; // 70%
                                }
                            }
                            salary =  fixedWage + monthlyBonus; 
                        }
                IF=>	IF(person.type == Person.CONSULTANT) {
                            dailyFee = 300;
                            workHours = aPerson.workHours();
                            realDays = workHours / 7;
                            salary = realDays * dailyFee;
                        } 
                        return salary;
                    }

Pretty scary,huh?

Yes, it is.
And it happens everyday all over the web.
So, what can I do to help?

Join Our Workshops Join Our Newsletter Join Our Community

Less IFs, more power