The Anti-IF Developer Path
Do you want to learn how to grow a software system by reducing its complexity over time? Do you want to develop software in a more sustainable and predictable way?
In software development, deadlines are more and more demanding. In order to deliver on time the changes requested by their clients, software developers often apply the "IF Strategy." By doing this, they increase the complexity of their software systems, create duplications and accumulate technical debt. Therefore, the next features to be developed will cost more and more. Changes will take an unpredictable amount of time to be made (the so called "never ending stories") or sometimes they even become impossible to be made. One IF at a time software development becomes unsustainable.
The Anti-If Developer Path is a selection of our training activities dedicated to developers who want to learn how, by replacing the "IF Strategy" with other design techniques, they can grow a software product capable of embracing change.
This training path is a series of seminars and workshops that enables software developers to learn a range of design techniques and patterns to deal with complexity, growth and change in an effective and sustainable way. By replacing the "IF strategy" with more effective design strategies you will be able to deliver your scheduled features on time.
Here you can find the next sessions of this path:
About this path
The Anti-IF Developer Path is the ideal training roadmap for software developers who want to significantly improve their design skills and change their perspective on how they conceive emergent design.
When it comes up to deadlines, you will learn not to rush but to stop, think and find a suitable design solution, getting help from the current design of your software system.
Taken along with your team, this path will grant all its participants to line upwards your design knowledge. You team will be able to define a "no-shortcut" shared design strategy to be applied under demanding deadlines to avoid accumulating technical debt and deliver on time.
What is the "IF Strategy"?
Let's consider a real case. Our company runs an online store software system.
We are settled in Germany and sell physical and digital products of various types all over the world.
The tax to be calculated on this kind of sales is called value-added tax (VAT) in Europe. We must calculate it and show it on our invoices.
Note
|
What is a Value-Added Tax (VAT)? A value-added tax (VAT) is a consumption tax placed on a product whenever value is added at each stage of the supply chain, from production to the point of sale. The amount of VAT that the user pays is on the cost of the product, less any of the costs of materials used in the product that have already been taxed.
|
Let's imagine we have to develop the software feature that chooses and applies the VAT rule correctly.
Customer: "The choice of the VAT rule to be applied depends on various factors. If the product sold is a physical product, a specific rule is to be applied. If it is a digital product, another rule is to be applied."
Developer: "Let's put an IF to deal with the physical products and another IF to deal with the digital ones. Simple and effective!"
Customer: "If the country where the product is purchased belongs to the European Union and the customer is an individual, a certain rule is applied: the "German VAT rule."
Developer: "I'll have to add more IFs. Bummer!
Customer: I'm not done... If the customer is a business registered in Europe, a special rule called Reverse Charge is applied..."
Developer: "I see..."
Customer: "Whereas, if the customer is a business but not registered in the European Union.... Well, another rule named VAT Exempt should be applied."
Developer: "More IFs... aaargh"
Customer: "I'm not done... It's obviously not that simple!
Developer: "...hm, I wonder how many more IFs I will need to do this feature"
Customer: "If you sell a digital product and if the customer is an individual... but only if they live in a European Union country... well, a different rule called MOSS must be applied."
Developer: "Nested IFs... Double bummer!"
Customer: "Maybe one day a country will leave the EU. Could you also consider this?"
Developer: "Nooooo it can't happen."
(BREXIT)
Customer: "Maybe one day a product that is not considered digital becomes so? Could you also consider this?"
Developer: "Noooooooo it can't happen..."
(Online courses are now considered digital products together with audio books, and mp3)
How many more IF statements do you want to add before taking the Anti-IF Developer Path?!
THE "IF STRATEGY": WHY?
"Let's add an IF" is the most widely chosen "design strategy" used by developers to manage complexity, growth and change. It is simple and immediate. But It is also the most damaging one.
One IF after another, your software becomes a dangerous code monster: an intricate mass of interdependent lines of code impossible to test, read or modify.
Objectives
As a result of this path, you will be able to:
- Get rid of bad IFs. You will be able to identify dangerous IFs (those that are used when you apply the "IF strategy" and cause a system to degenerate into a Code Monster) from physiological IFs. You will also learn how to transform those dangerous IFs into good code by incrementally implementing new user stories.
- See and recognize the flow of design dependencies and be able to organize them in a conscious way, fearlessly 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 complexity.
- Grow software incrementally while maintaining maximum quality and delivering the highest possible number of functionalities.
Related Activities
We recommend that you combine this training path with: