Nietzsche on Agile Software Development

Not serious, , ,

DISCLAIMER

What you are about to read is almost completely wrong. I’m obviously not a philosopher so don’t hold it against me please. This is also a huge shortcut of what Agile really is, and what values it really relies on. It also features a couple of myths and commonplaces about Agile and non-Agile thinking. In fact this article is a joke.

Background

Before the Agile era begins in the mid-1990 early-2000, software development methods was essentially copied on age-old methods from industry or architecture. The common belief was that the biggest the requirements are, the better the end-result will be, and the more details we have before we start, the better the design will be. So before coding actually starts, projects had to go through several specification-validation loops. When the requirements were eventually accepted and the design finally validated, the documentation mass could be transmitted to the development team which had to “do it”. So the thing was as follows:

No need for good developers as long as the process is followed scrupulously.

…that was a mistake, and Friedrich Nietzsche warned us about it long ago.

der Wille zur Macht

An important component in Nietzsche’s philosophy is what we usually designate as “Wille zur Macht“, the will to power. Nietzsche believes that the number one driving force of human beings is his will to power: the will to reach the highest position, the will achieve more, the will to have control on things we do, on things that surround us.

Earlier, Arthur Schopenhauer identified the will as being the driving force of all things, especially the will to live. In Die Welt als Wille und Vorstellung, he defines will as the kernel of everything. Will can be found behind every desire, every expectation, every wanting.

Nietzsche, who were influenced by Schopenhauer, precises that this particular will that drives human beings is the will to power, not only the will to live.

In the posthumous book Der Wille zur Macht, Nietzsche write:

My idea is that every specific body strives to become master over all space and to extend its force and to thrust back all that resists its extension.

The problem with pre-Agile methods

Pre-Agile methods emphasize processes, documentation, specifications and requirements. This over-usage of pre-coding documentation is meant to force developers to code in the exact way that the architect want them to code, theoretically ensuring that the result will be what the architect designed; and what the client wanted provided that the architect followed a same set of rigid methods and processes.

In industry this kind of reasoning can possibly work if workers’ field of action is restricted to the bare minimum. The problem with software development is that the field of action of developers cannot be restricted in such a way that they only have to put a screw in a piece  metal. Software development is not an industry, it is a craftsmanship, and this includes some creativity. According to Merriam Webster a craftsman is “one who creates or performs with skill or dexterity especially in the manual arts“.

You cannot restrict a graduated man with a high skill level into following scrupulously a huge specification and architecture document. His nature, his will, will struggle, fight for more space. The guy will start thinking : “Hey!? What the f*** is that? This architecture is just a non-sense!”, “I would have done better”, “Ok, they want me to do that, I will do that…but it’s completely dumb” or even the famous “It’s not a youngster like him who will teach me how to do my job”. Will needs space…and responsibilities.

The Agile way

The Agile manifesto reads as follows:

We are uncovering better ways of developing
software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,

Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

The most important part here is “Individuals and interactions over processes and tools”.

The Agile philosophy is based on the principle that people are more important than processes, and grant them with more responsibilities, give them more space. Now developers have enough room for their will to expand. They can interact directly with the client, their team is self-managed, there is no heavy architecture adopted without the team consent, they are responsible for designing the application at a code level, including the OOD, etc.

Clearly the developer becomes the center of a project…but this does not mean anarchy. This means responsibilities. There is no way to hide behind a project leader : the team has committed itself. The code must be clean : someone else is coding in this part tomorrow. We have rules to follow : not the ones from an enterprise architect but the ones the team has given to itself.

Conclusion

In the 19th century, Nietzsche already knew that individuals were the center of all things. He knew that the will is almighty, that the will to power is what drives people, that people need more responsibilities, need to be considered as what they are, need to become better than what they used to be, need to achieve things. This is what Agile methods do by placing people in the center and considering developers as what they are : craftsmen.

…Ok I’m out.

References And Readings

“The Clean Code Talks” are fighting if statements

Programming, , ,

Just found this 4-year-old video which can be very instructive :  Misko Hevery fights against if/switch statements using object oriented techniques to remove them.

“The Clean Code Talks — Inheritance, Polymorphism, & Testing” – YouTube.
Continue reading “The Clean Code Talks” are fighting if statements →

if-else trees vs SOLID principles

Programming, , , , , , , , ,

Introduction

If you have read my previous articles, or know me personally, you must know that the one kind of bad code I hate the most is if-else trees. In the first article of this weblog, I talked about if-else trees in general, exposing some general ideas about how to avoid them, remove them from the code or why they are bad, describing them as a code smell.

Today, as I have just finished writing a series of articles in French about the SOLID principles, I am going to focus on the maintainability aspect of if-else trees, and make them fight against two of the SOLID principles: the Single Responsibility Principle and the Open/Closed Principle. This will allow me to introduce some important rules to know about if-else trees. Continue reading if-else trees vs SOLID principles →

SOLID Partie V : Dependency Inversion Principle

En français, Programming, , , , , ,

Introduction

Le Dependency Inversion Principle (DIP) réside en deux règles:

  1. High level modules should not depend upon low level modules. Both should depend upon abstractions. ( Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d’abstractions.)
  2. Abstractions should not depend upon details. Details should depend upon abstractions ( Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.)

SOLID Partie IV : Interface Segregation Principle

En français, Programming, , , , ,

Introduction

Comme toujours avec les principes SOLID, l’enjeu est la maintenabilité du code. On s’intéresse en particulier au couplage. Si ce n’est pas déjà fait, je vous invite à lire SOLID Partie I : Single Responsibility Principle car les idées défendues dans l’Interface Segregation Principle (ISP) sont proches de celles du SRP. En effet, alors que le SRP défendait l’idée qu’une classe ne devrait avoir qu’une seule responsabilité (“il ne devrait y avoir qu’une seule raison de changer une classe”), l’ISP va plus loin en appliquant ce principe aux interfaces. Continue reading SOLID Partie IV : Interface Segregation Principle →

SOLID Partie III : Liskov Substitution Principle

En français, Programming, , , , ,

Introduction

Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T.

 Barbara Liskov, Jeannette Wing, “A behavioral notion of subtyping”,1994

Liskov et Wing définissent un sous-type (ou une sous-classe) par substituabilité : S est un sous-type de T si l’on peut toujours remplacer un objet de type T par un objet de type S.
Nous n’allons pas rentrer ici dans les aspects théoriques de cette définition, ni détailler les travaux de Barbara Liskov, mais retenons simplement ceci : une sous-classe n’est une sous-classe que si elle se comporte comme sa classe mère, c’est-à-dire que l’on peut remplacer une instance de la classe mère par une instance de la classe fille.

Le corollaire de ce principe est qu’une sous-classe ne doit pas rompre un “contrat” établi par la classe mère. C’est le Design By Contract de Bertrand Meyer Continue reading SOLID Partie III : Liskov Substitution Principle →

SOLID Partie II : Open/Closed Principle

En français, Programming, , , , , , , , , ,

Introduction

Dès lors qu’un logiciel est, avec le temps, amené à être modifié, que ce soit afin d’y ajouter des fonctionnalités ou de modifier certains comportements, des problèmes de régression se posent. Au fil des versions la qualité tend à diminuer et la maintenabilité aussi. Continue reading SOLID Partie II : Open/Closed Principle →

SOLID Partie I : Single Responsibility Principle

En français, Programming, , , , , , ,

Introduction

Robert C. Martin, le père de SOLID, introduit le Single Responsibility Principle (SRP) en ces termes:

“There should never be more than one reason for a class to change.”

“Il ne devrait jamais y avoir plus d’une raison de changer une classe.” Continue reading SOLID Partie I : Single Responsibility Principle →

SOLID – Introduction

En français, Programming, , , , ,

On peut constater que la plupart des développeurs qui utilisent quotidiennement la programmation orientée objet connaissent généralement non seulement ses grands principes (interfaces, classes, héritage, polymorphisme, etc.) mais aussi une ribambelle de design patterns qu’ils essaient de placer un peu partout, sans forcément en connaître les subtilités. Continue reading SOLID – Introduction →

smell of if

Programming, , , , , , , , ,

A code smell is a hint, a clue which indicates that a potential problem is hidden somewhere in the code. Some of them are well-known by every developer, like too long identifiers, too short identifiers, duplicated code, too many parameters, dead code, etc.

Today, I’m going to tell you about a particular code smell that I recently had to fight against. Failing to find an official term, I will simply call it the if-else tree. Continue reading smell of if →