Anti-IF Programming

Defusing the IF-Strategy

The IF-Strategy

Have you ever wondered how IFs impact on your 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?

Less IFs, more power

Faq

Originated by Francesco Cirillo in 2007, the Anti-IF Programming approach has transformed how many perceive IFs and conditionals in software design. At the heart of software design lies a simple yet potentially dangerous tool: the conditional 'IF' statement. Undeniably foundational, its use to handle changes in a growth context, dubbed the "IF Strategy", can be a silent saboteur, complicating code and tangling logic. The IF Strategy can lead to debugging problems, never-delivered user stories, technical debt, entangled design, frictions in the team and other inefficiencies. In essence, the IF Strategy can escalate costs and delay software delivery times while degrading internal quality.

Questions