Goal: Defuse the "IF Strategy" to reduce the cost of change

"In my daily work as a software developer, deadlines are more and more demanding. In order to deliver on time the changes requested by my customer, I often apply the 'IF Strategy.'

By doing this, I increase the complexity of my software system, I create duplications and accumulate technical debt. Therefore, the next functionalities to be developed cost more and more. Changes take an unpredictable amount of time to be made (the so-called 'never ending stories') or sometimes even become impossible to be delivered. My work becomes a nightmare 'One IF at a Time.' I create Code Monsters 'One IF at a Time.'"

Here you can find the next three sessions of this goal:

About this Goal

In order to reach this goal, you have to develop your software design skills. You need to learn how to replace the "IF Strategy" with more effective design strategies that will enable you to reduce the complexity of your software system and deliver new functionalities on time and in a sustainable way.

What is the "IF Strategy"?

The "IF Strategy" is a way of dealing with growth, change and complexity in software development.

Whenever we need to deal with a change in the behaviour of our software system, we CAN do it by introducing an IF statement (the "Let's Put an IF Syndrome") :

IF ( new condition ) { new code }

Why do developers apply it?

Because it is simple:

• Put an IF
• Add a condition
• Add the related behaviour

Done! The problem seems to be solved forever.

But... What does really happen to your software system over time?

Of course, by consistently applying the "IF Strategy" the structural complexity of your system will grow over time. One IF at a time, you will make your system more complex to be read, tested, even debugged. It will become "easier" to duplicate code. Inevitably, you will end up accumulating technical debt all the time.

	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;
	 }

Interested in the Anti-IF Campaign? You can join the Campaign here.

Our Solution to Reach Your Goal

Defusing the "IF Strategy"

By replacing the "IF Strategy" with more effective evolutionary design techniques you can break the vicious circle that starts every time you receive a new customer request:

=> 1. new IF(s) => 
=> 2. more complexity (=less readable and testable code, system hinders change) => 
=> 3. more technical debt =>

By defusing the "IF Strategy," you will be able to reduce the complexity of your software system over time.

It will be easier to define a "no-shortcut" design strategy to be applied even under strict deadlines and deliver your customer requests on time without accumulating technical debt.

To defuse the "IF Strategy," you have to learn to deal with two dIfferent aspects:

Technical Aspect - You have to learn how to replace the "IF Strategy" with other evolutionary design techniques that will enable you to grow a software product capable of "embracing change." This means that you need to develop your skills to:

• Distinguish dangerous IFs from physiological IFs. Dangerous IFs are those that you use when you apply the "IF Strategy" in an evolutionary context. These IFs make a system degenerate into a Code Monster!
• Get rid of bad IFs. You also have to know how to transform those dangerous IFs into healthy design structures and modules able to reduce the complexity of your software system.
• Visualize the design dependencies implied in your software system and be able to organize them in a conscious way, confidently and without rush.
• Identify effective solutions without running the risk of over design. A dangerous IF can be eliminated in many different ways. Not all of them are able to reduce the complexity of your software system.
• Grow software incrementally maintaining maximum quality and delivering the highest possible number of functionalities.
• Use Objects and Patterns in an incremental way to flatten the cost of change curve.
• Monitor the cost of change related to your software product in order to measure if your design solutions are really reducing the complexity of your system.

Psychological Aspect - You have to learn how to stop and think in order to find a suitable design solution, even if your feel under the pressure of a strict deadline. You don't need to rush. You need to learn how to get help by the current design of your software system.

The Solution Plan

Our solution is a combination of seminars, events, mentoring and workshops that enables you to learn a range of design techniques to deal with complexity, growth and change in an effective and sustainable way.

Upcoming Sessions

Here you can find the next sessions of this goal:

Can't make it on any of our dates?

We can discuss other options with you

Testimonials

Carlo Garatti

CEO, Caplab

Feedback after attending the course: you must attend! Seeing how and why Francesco makes software design decisions is super helpful in improving how you make your decisions!

Useful Resources

FAQ

Do you have a question not listed here?