
by Loris Pozzobon | Aug 14, 2019
Imagicle: why choosing emergent design for Agile software development.
Want more awesome content? Sign up for our newsletter.
“The best architectures, requirements, and designs emerge from self-organized teams”. This is one of the Principles behind the Agile Manifesto I’ve briefly discussed in a previous post, talking about Sprint Planning. But it turns out to be a very useful point here today, as we’ll look at what elements we can leverage to create shock-proof software architecture and how Imagicle self-organizing teams allow the design to emerge.
Building a bridge. The problems with the upfront design.
- define the requirements;
- make arrangements with the client about what, how and when it will be done;
- design the solution;
- implement the solution;
- deliver it to the client.

- it has precise requirements (what should be done, for how long it should last, etc.);
- the requirements do not change during construction (it is rather difficult to imagine that the client, with work in progress, says something like: “Listen, could you get it 1 km further downstream?”);
- doesn’t need to be developed for future modifications or extensions;
- if there are any doubts, they are known: i.e., I don’t know how many kg/m2 that foundation can hold, so I know I have to to find out;
- building the bridge is much more expensive than designing it.
Well, let’s see which of the five factors mentioned above are typically respected in a software product.
1. Precise requirements.
Nothing like it. Usually, the requirements become clear as the product takes shape. And since we prefer to make our users happy rather than tell them “You signed for this 6 months ago”, the continuous feedback from users is much more important to us than the initial negotiation of the requirements. (Customer collaboration over contract negotiation – Agile Manifesto).
2. Stable requirements.
No: it happens all the time that some requirements change during the development, new ones come out or that which at first seemed indispensable end up being excluded. The market changes quickly, the needs change quickly, so the software must change accordingly (Responding to change over following a plan – Agile Manifesto).
3. Changes in progress.
Modifications and extensions are a daily occurrence when working on a software (think of all the news included in each release of our products ).
4. Doubts.
We are aware from the beginning of not knowing some aspects. But we discover other flaws the moment we encounter them. A bit like saying: if you know you don’t know, feel lucky…the problem is when you don’t know you don’t know (little spoiler, we’ll see shortly that it’s better not to try to solve even the doubts we have in advance!).
5. High modification cost.
Emergent design.
A real use case: the Imagicle ApplicationSuite Web Services.
A good software architect could have said: “Well, since from now on we will write a lot of classes like this, let’s think about how to structure it, and then we think of a framework that makes it easy and fast to write similar classes.”


And what about the tests?
Well, we had come to have our first two Web Services with a very simple abstract class that shared a small piece of code. After a while, it was time to write the third Web Service, this time having some infrastructure ready.
But, as you can guess, it’s not all peaches and cream. Another trap is lurking.
Mind the trap.
- this assumption is based on the knowledge of the implementation of the three Web Services, which, as we have seen, is not the correct way to interpret the automatic tests. What if tomorrow, following a refactoring, that portion of common code would stop performing the functionality we decided not to test? That functionality would fail, and we wouldn’t even notice it;
- the fact that the other two Web Services, today, must have the same behavior as the third one (with regard to the part expressed by the common code), does not necessarily have to be valid tomorrow. Tomorrow we may want to change the tests that model that behavior in the first two Web Services, make the code common so that they pass and break the behavior of the third Web Service that was expected to behave as before.

Strange case of software design.


“A good architect maximizes the number of decisions not made” – Uncle Bob (Robert C. Martin).
“Working software over comprehensive documentation” – Agile Manifesto.

Conclusions.


0 Comments