The architect Christopher Alexander worked intensively on the question of how rooms, houses, districts and entire cities must be built so that they convey liveliness. The result of his research was, among other things, a book for sad and frustrated people – the book “A Pattern Language” written with Sara Ishikawa and Murray Silverstein (collaboration: Max Jaconson, Ingrid, Fiksdahl-King, Shlomo Angel), which, when read in dreary hours, makes one cheerful and cheerful. This book does not contain best practices, but rather frequently occurring good practices, i.e. architectural solutions that have already proven themselves many times. Many of these architectural solutions are not the genius of architects, but everyday common sense. Others belong to the hopefully self-evident basic knowledge of architects. Some are also rather esoteric, and one may not always be able to relate to them. But almost all of them are thought-provoking – about what works and what doesn’t in buildings and cities. Similarity to Cage Christopher Alexander’s approach to the built reminds one of John Cage’s relationship to the sounding – as much as architecture and music are opposites, since the built aims at permanence and the sounding at transience (music sounds and fades, and that is an essential part of its appeal). Cage asks us to listen carefully to sounds in order to recognise their beauty, and he has created chance compositions that take away the importance of the composer. Alexander asks us to look closely at buildings to see the architectural beauty in the non-spectacular, and he has developed principles of good design that in a way also take away the importance of the architect. Alexander’s importance The reason Alexander is important to e-government is first and foremost a historical one. Alexander’s pattern language inspired the design patterns of computer science (“design patterns” of the so-called Gang of Four) and through them the development of pattern languages in all areas of computer science and its applications. In addition, anti-pattern languages describing bad practices were also developed in computer science. Bad practices are not outlandish mistakes in the design of computer science solutions, but common errors that cause serious damage. Just as pattern languages are not above suspicion because they occasionally claim to be esoteric in meaning, anti-pattern languages are not always free from suspicion of serving the exercise of vengeance. Those who write an anti-pattern language book may be tempted to settle one or two scores. More often, of course, unnecessary precision or political correctness celebrate reigns and lead to long-winded descriptions. The emptiness of e-government One would now expect that there would be numerous books on good practices and bad practices in e-government as well. But far from it. On the one hand, the best-practice paradigm still applies, which means that solutions are only interesting as long as they are particularly advanced. Whereby – and this is particularly shocking – poorly built showcase solutions are more interesting as examples than truly excellent solutions that may only emerge years after initial implementation. On the other hand, bad practices are considered a no-go because one has to provide concrete examples and these examples are examples of mistakes that individuals are responsible for. But that is frowned upon as criticism of individuals. The result is a great void in the teaching of e-government – without right or wrong. Right and wrong empathy If more empathy were practised towards the cause itself – instead of empathy with the sensitivities of those who spoil it (I am not excluding myself here) – then e-government could finally become a professional discipline, for the benefit of the cause. It is a matter of course in many disciplines that representatives of their field firstly use standard solutions for problems that amateurs do not even see (professional work uses many patterns), and secondly recognise bad solutions. Only in e-government is such a thing unknown. Thirdly, unsatisfactory solutions that are used in practice due to a lack of better alternatives would no longer be so often unjustly criticised by know-it-all academics. Language for e-government It would therefore be time to leave behind the previous indiscriminateness of good and bad solutions and the trendy value orientation in e-government (OGD good! Mobile good!). Instead, we should concern ourselves with the question of what good practices and what bad practices are in e-government, and then communicate this knowledge to the e-government specialists. Above all, it would be important to look very closely in the future at what constitutes quality and not to be afraid to talk about mistakes. What we need is a model language and an anti-model language for e-government – with their own dialects for project managers, solution designers, engineers and lawyers.