13/02/2024
It is a well known truth, beyond any dispute, that the world can be divided into three types of people: those who believe that the world can be divided into three types of people, those who don’t and those who aren't sure.
Whilst I don’t particularly like dividing people up into groups, I have found, over many years, that modellers and programmers can mostly be divided into two distinct groups - the complexifiers and the simplifiers.
The complexifiers love complexity. They see complexity as a good thing - often as a mark of quality. They will sometimes pursue complexity as an end in itself according to the principle that anything that isn’t complex should be made complex if it can be made complex. Complexifiers in modelling will use obscure modelling/programming language features just because they are there. Complexifiers are often seen from the outside as being high value, intelligent, and indispensable to a project. This is because no one else can understand what they have done.
On the other hand, simplifiers (and I include myself in this camp) dislike complexity. They will seek to remove complexity at every turn. If something is complex, they will try to make it simpler. Worst case, they might simplify too much, and, “throw the baby out with the bath water”. Simplifiers are often seen from the outside as being low value and not too bright. After all, their work products are so easy to understand - even obvious. Simplifiers limit themselves to the modelling/programming language features that they actually need, and hate obscure features that few understand. They are often seen as dispensable to a project, because, after all, if it is so simple, then surely anyone can do it.
I think you can see where I am going with all this. Who do you want on your project? Someone who makes things seem complex and difficult, or someone who makes things seem simple and easy.
Michael Jackson (no, not that Michael Jackson - THE Michael Jackson, the father of Jackson structured programming) tells an interesting story about visiting a project that I shall summarise here because, sadly, I can’t find the actual reference. In fact, this is a koan of sorts, provided you use the term "koan" very loosely:
“Jackson went to visit a project in action. The project manager introduced the team and said, “this is Bob and Bob is a great programmer. Every project we give Bob proves to be really difficult and complex, but Bob always provides a solution. We don’t know what we would do without Bob, because no one else understands the really complex work he is doing.” The manager went on to introduce Alice. “And this is Alice, we’re not sure how good Alice is yet, because every problem we have given her has turned out to be easy. She still has to prove herself”.
Wow! That just about sums it up.
When Ila and I write a book, the reaction we are looking for from our readers is, “Well - that was easy - just common sense really”. We try to get this reaction to even very abstruse, complex and subtle ideas. It is a fun game, and we don’t always succeed, but we always try as hard as we can. We do this because we know that when the reader has that reaction, the information we are trying to impart has been completely integrated into the readers cognitive map of reality. It has become “obvious”, it has become “common sense”, it has become “just the way the world works”.
Normally, extending someones map of reality involves them going through an uncomfortable state of cognitive dissonance where the new ideas in the extended map clash with the old ideas in the old map. But with a lot of hard work, a lot of this dissonance can be finessed away. This is what we try to do.
A big part of this is striving to simplify - to make things as simple as possible but no simpler. Another big part of this is presenting the information in an appropriate form (we discuss this in depth in Generative Analysis) - using structured text, pictures and models as appropriate. This takes a lot of effort, but, in our view, it is worth it.
20 Jul 2017 at 13:26 (updated Feb 2024)