Atrocities of Software Architecture

Five years ago I’ve written my definition of a software architecture and have compared two alternative architectural designs: Monolyth vs SOA. For each design, I gave its advantages and disadvantages.

Now, five years later, I’ve learned a little more and want to amend this topic.

It has turned out, that in the organizations in the Enterprise Autumn phase, many decisions are made not out of best fit for the situation, but purely due to political reasons. Besides, due to Murphy’s Law, some implementors of the architecture have achieved their level of incompetency.

This can lead to a situation when additional disadvantages (for the enterprise) can emerge, which are not intinsic to the chosen architecture, but are just results of a wrong practical implementation strategy or political processes. Therefore, when describing and comparing possible advantages and disadvantages of some architectural design, for a proper decision, you also have to take into account its possible atrocities.

Atrocities of a Monolyth

  1. One usual atrocity of a monolytic application is the insisting on full re-test of the whole application on each and every release. Even though it is possible to retrieve the list of changed files and therefore exclude large parts of the application unaffacted by the change from retesting, people could reject that idea, thereby forcing many parallel developments to wait for a long time to be released,  as well as wasting the time of testers.
    To be able to decide about skipping some parts of the app from retesting, you need a) to know exactly what code is reused where, that is, you need to be able to know the source code of the whole app and be able to read code diffs quickly – not a skill that is completely impossible to learn (look at Linus Torvalds as an example) and b) want to take some minor risks (below 1% of chance) in order to facilitate more product lauches per year – something that people are told not to do, especially in the Enterprise Autumn phase, where the fear of the founders to damage the flywheel overweights their need to innovate.
  2. Another atrocity of the Monolyth is reusing it for any other software made by the company. You want to develop a new product, quite different from the first one, to become a second flywheel? No problem, we will put it inside of the existing Monolyth, because well, we can reuse some unimportant code from there (like the “about us” page and the ORM framework). Thus, a chance is missed to create a completely new project, which is not dependent on the first one and therefore that can be deployed independently.

A properly implemented Monolyth tends to be eagerly and on every suitable occasion splitted into several interdependent Monolyths. Creating a copy of the app in another language? New Monolyth. Creating a new area of the app not tightly interconnected with the other parts? New Monolyth. Besides, a properly implemented Monolyth would aggresively defend all opinions asking for full re-test on each update.

Atrocities of SOA

  1. M. Conway has stated the following law in 1967: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” In case of the microservices, people would assign sub-teams to own one or several services. Because services are usually designed to be very small, as a result, changing one simple thing on the web site, requiring changing of several services, would make from it a huge project including very slow and expensive coordination of 3 teams (eg. 15 developers).
    This atrocity alone would lead to even longer time-to-market cycles compared to the monolyth. In a properly implemented SOA, every developer can develop any (or most) of the microservices, therefore, it is normal, for one team to change several services in just one week.
  2. Another atrocity is the wish to make everything to be a RESTful microservice. Some reusable modules, cloud services and databases have other interfaces, be it RPC, Protobuf, AMPQ or proprietary protocols. These communication protocols are carefuly designed, sometimes in the course of several decades, to provide imporant run-time properties (eg. automatic failover and cluster management, reduced overhead on serialization and connection establishing, coonection pooling etc). There is not so many reasons to implement a REST wrapper around them.
    In a properly implemented SOA, RESTful services are usually introduced only due to these two reasons: a) we want to communicate to “fat clients” (eg. mobile apps, modern HTML5/jQuery apps) over the public Internet, or b) we have some important business logic, which cannot or should not be encapsulated in the database (eg. using stored procedures or views), so that we need to develop and host a separate service process anyway.
  3. Yet another atrocity is that some teams would consider a microservice to be a deliverable (a completed piece of work, even a product), whereas a service is similar to one OOP class or package / module / assembly, that is a technical module, just a part of a product. You will never start creating a product with a service. In a properly implemented SOA, you will conceive and develop the UI and UX first, derive the API for the service according to the calls the frontend needs to made, and then use or develop the corresponding service or services.

Common atrocities

  1. Over-Engineering. If you imagine quality to be a number from 0 to 100%, some people are unable or unwilling to deliver any given quality level. They can just give the level 0% or the level 100%. What real world business situation usually requires is the level of 60%, sometimes being dropped to 30%. A properly run software development organization can deliver any required level of quality.
  2. Death by Security. If you imagine security to be number from 0 to 100%,… see above.
  3. Checklist-oriented development. Some people do things described in the checklists, formal quality criterias or common conventions, without checking first whether these things matter in the particular situation, do they add up to some desired property of the software, or maybe even counter-productive?
  4. Mandated Architecture. In the year 2018, it is impossible to mandate software architecture by a HiPPO, nor enforce it using architectural nazis running around with whips. If tried to do so, the architecture will invariably mutate to some of the atrocities described above, when implemented by the people who either a) don’t agree with it or b) don’t understand how exactly this architecture is going to solve their pains. A proper architecture is always something everybody unanimously (100%) agree to be The Good Thing to do, and usually it can only evolve from the trenches, not mandated from above.


In the year 1975 when I was just born, Frederick P. Brooks has already learned about software development enough to write his essay “There is no silver bullet”. Applying this principle to the architectures, one could say, any theoretical advantage of any architecture can be missed by a poor execution. Or, like Derek Sievers uses to say, idea is nothing, execution is everything.

My stance on privacy

Making decisions is important part of life. Good decisions can improve, bad decisions can ruin life. Historically, people have used their intuition to make decisions.

With the improvement of computing and data processing, people have gradually started to use data to measure decision quality and to improve it. In business setting, this is known as business intelligence. Some people are also using it to decide about their personal life.

With the raise of Big Data and AI, data is not only feed to humans to assist them making good decisions, but also AI systems, trained according to goals set by humans, have started to make decisions on their own, either without or with some very limited human involvement.

This all has changed the role of data and increased its value. Suddenly, we have to consider, how our own data is collected and processed. While nobody would mind sharing the fact they are smoking to the whole world only 100 years ago, people today would object against it, because they worry their health insurance company would use this data to make a decision and to increase the insurance fee.

If we want to infuence data-based decisions made about us, we have three ways:
1) not sharing relevant data about us,
2) having law preventing the use our data to make specific decisions, or
3) use our own data and make our own counter-decisions

In the example above, we either
1) stop sharing the fact we’re smoking to the world, or
2) we vote for law makers who will pass a law prohibiting health insurance companies to vary their fee from person to person, or
3) we use the data about the insurance company to find out that the surplus of extra fees gathered from smokers was spent to pay bigger bonuses to the management, and left this company to a competitor. This option would require laws forcing companies and governments to be reasonably transparent about their data, as well as availability of competition on the market.

Now, it is important to understand that data-based decisions don’t need to be always bad for us. As a non-smoker, I like the idea to charge them more than average for health insurance, and as an overweight person I’m ready to pay more than average myself. And I like that people with small income pay much less taxes. And it would be nice if the fee in my wrong parking ticket would consider the fact that in the 99,9% of cases I pay for parking my car. And I have stopped watched TV because I can’t stand this annoying, un-personalized and sometimes insulting advertisement – I really like the advertisements Facebook and Google are showing me.

So, to benefit from this kind of decision making, I need to share my data. Therefore I find it pity that current european law-making in this area is mainly focused on making sharing of data more harder and complicated.

If nobody would share data, nobody would get hurt by some data-based decision. But also nobody would benefit from it. So our digitalization level will remain to be blantantly low and our decisions will still be made by some guts feeling like in the stone age.

I don’t think it is reasonable trying to stop data sharing. They say, when the first cars hit the roads of the cities, and the first car accident deaths happened, the law makers have issued a law requiring a person with a red flag and drums to march in front of the car, to warn people and horses. I could imagine this could prevent deaths efficiently, but this has undermined the whole idea of driving cars.

Today, we as a society have accepted many thousends of car accident deaths and injuries per year, because the benefits cars provide to the people and to the economy have far overweighted the risks. I think, the same process will happen with our data.

We will be sharing our data, in the future, much more than we’re doing it now, willingly or unwilligly, and we will have to learn how to deal with it. Our law today prevents collection and storage of the data. The future law will concentrate instead on regulating the decisions that are being made based on the data, making it is illegal to make unfair decisions, and making the data of the decision-making entities reasonably transparent to the public.

Another issue I want to point out in the current EU legislation is the definition of so-called personal data. As we all know it is the data that identifies or can identify a person. Let’s say, an email address. If a website would store email addresses entered by their users, this information is considered to be personal data and is thoroughly regulated. But what is the risk of storing some email address in some database? If nothing else is stored there, the worst thing that could happen is that somebody would send some spam to this email address, or try to phish corresponding password.

But let’s now say, for instance, besides of the email address we would store the person’s income. Income is not personal data per se, so that no additional regulations would apply in this case. But the risk of abusing or leaking this information is much greater!

Another example: let’s now replace the email with the ip address, so now we have a table of ip addresses and their salaries. According to the German regulators (this is not in the GDPR itself) the ip addresses are personal data. But leaking of this information would lead to virtually no risk. Neither bad web site owners nor hackers have enough capacity to map ip addresses to real persons, at least not in a scalable way for massive amounts of the data. Still, according to the law, this data will be protected in the same way as the data containing email adresses.

My suggestion to that is to abandon the “personal” from the future regulations. There are just data owners, who share their data to somebody else, and this somebody else will have to comply to some set of rules (for example, must disclosure all the data used to make a specific decision), no matter what kind of data has been stored and processed.

Smart UX

These are the levers to open subway car doors:

If you pull them during the move, nothing happens, because they are locked for safety. Also, no indication to you as a user will be displayed. Also, there is no indication about whether they are currently locked or unlocked. If you are an experienced subway car doors user though, you can hear the sound of unlocking and then understand that you can now pull the levers.

And this is the button to open doors of the new subway car:

They have added a visual indication of whether the doors are locked or unlocked, the LEDs around the button. But there is more in it, the feature that I would argue belong to the new generation of the Smart UX, a combination of Smart Data and UX.

If you look at the old lever system from the data perspective, the user is giving you the signal about his intention to open the door. If the door is locked, safety of the user is ensured by not opening the doors, but also his signal is not used and it gets lost.

As for the new button, you can push it also when the car is moving and the door is locked. The door will use this signal to understand your intention, to remember it, to indicate to you using a special combination of the lighting LEDs that it knows you want to exit, to wait until the car stops at the next station, and then to unlock itself automatically.

Not only the Smart UX is more comfortable for the user because it reduces the amount of interaction required to open the doors, as well as the amount of knowledge about the current lock state required to be able to operate the doors successfully. But also the robotic system shows more respect to its human user by acknoledging his presence, remembering that the user wasn’t successful at the last interaction, and being polite and helpful by trying to predict his next actions.

I’m not saying that the new button is in any aspect better than the old levers. It could be that the levers are easier to understand by people who maybe arrive from 3rd countries, never have seen round buttons before and don’t come to the idea that they can be pressed. And the levers are more similar to usual door handles and thus easier to understand by that category of people. Also, in case of a malfunction, the doors have to be unlocked and pushed aside manually and mechanically – operating the levers could be easier than trying to open the doors without any handles.

What I’m saying is that a modern, Smart UX considers any user interaction as a data signal, exposing the true user intention, and it doesn’t waste any single bit of this signal, but uses it to build up a mental model of the user intention and to act according to it.

Singularity 1

Der technologische Fortschritt läuft immer schneller, so dass der Gap zwischen dem “Modernen” und dem “Bewehrten” immer größer wird. Eigentlich bereits jetzt so groß, dass die Verständigung zwischen den zwei Welten teilweise nicht mehr möglich ist.

Ein Beispiel dazu ist die vom Dobrindt angestoßene Ethik-Kommission, die sich letzte Woche gesammelt hat, um festzulegen, was (so wörtlich) “die Programmierer dürfen und was nicht”, wenn sie die Algorithmen für die selbst fahrenden Autos schreiben. Die Vorstellung der Politik, dass die selbst fahrenden Autos tatsächlich irgendwo den Code nach dem Motto “if rechts(is ein Fussgänger) then fahre(links);” haben, ist dermaßen realitätsfremd, dass einem zunächst einmal die Worte fehlen.

Im besten für die Ethiker Fall (der ziemlich unwahrscheinlich ist), ist dort das System in zwei Teilen aufgeteilt:
a) Erkennung einzelner Objekte aus einer Menge der farbigen Pixel
b) Vorhersage der relativen Positionen und Geschwindigkeiten dieser Objekte, relativ zum eigenen Auto, um rechtzeitig bremsen oder ausweichen zu können.

Dabei könnte es sein, dass man die erkannten Objekte klassifiziert (“Haus”, “Mensch”, “Auto”), um den Punkt “b” besser vorhersagen zu können. Das muss aber nicht sein, weil man allein aus dem Volumen der Objekte (angenommen eine durchschnittliche Dichte) ihre Masse und dementsprechend ihre Trägheit gut genug abschätzen kann.

Viel wahrscheinlicher ist aber, dass man für die selbst fahrenden Autos der Zukunft Deep Learning einsetzt. Beim Deep Learning werden die farbigen Pixel als Input für eine Blackbox geliefert, und diese Blackbox so lange trainiert, bis sie vernünftig fahren kann. Ob diese Blackbox irgendwo intern die Begrifflichkeiten “Raum und Zeit”, “Materie”, “Objekt” und “Mensch” entwickelt, sozusagen als Zwischenschritte von farbigen Pixeln zur Position vom Lenkrad und Gaspedal, ist ungewiss, zufällig und ändert sich von Version zu Version.

Beim Deep Learning wird die subjektive Zeit, die innerhalb der künstlichen Intelligenz herrscht, so komprimiert, dass dort die gesamte Entwicklung der Intelligenz auf der Erde (von Zellen bis zum Menschen) in mehreren Tagen unserer Zeit verläuft, zumal die künstliche Intelligenz in ihrer eigenen Welt unsterblich ist. Diese Entwicklung wird bei jedem Training-Versuch wiederholt, bis ein für Menschen gewünschtes Ergebnis erreicht wird.

Und ob die künstliche Intelligenz bei ihrer Entwicklung den gleichen Weg wie unser einschlägt, mit der klassischen Logik, dem Raum und Zeit-Konzept, der Farbenskala, mit Licht und Ton, mit der Einteilung in lebende und nicht-lebende Gegenstände, dem Phasenkonzept Plasma-Gas-Flüssigkeit-Harte Gegenstände, dem Konzept von Leben und Tod, und letztendlich mit den Straßenkennzeichen und “dura lex sed lex”, oder irgendeinen anderen, ist dem Zufall überlassen. Es ist eher anzunehmen, dass die Intelligenz der fahrenden Autos eine ziemlich andere sein wird, allen dadurch, dass sie die Welt durch ihre Sensoren ganz anders sehen und dass sie ihren “ich” eher mit nicht-lebenden Gegenständen verbinden.

Es wird also nicht möglich sein, für den “Programmierer” den Algorithmus so zu schreiben, dass die Autos das Menschenleben bevorzugen. Weil die selbstfahrende Software-Intelligenz keine Algorithmen hat, zumindest keine von Menschen geschriebenen (und übrigens, nur am Rande vermerkt, der Beruf “Programmierer” existiert spätestens seit 90-er Jahren nicht mehr, weil das “Programmieren” in der modernen Software-Entwicklung nur einen sehr kleinen Zeitanteil annimmt und nicht als ein Vollzeitjob ausgeübt werden kann.)

Wir werden die selbst fahrenden Autos vielmehr trainieren bzw. erziehen müssen, dem Menschenleben mehr Wert zu geben. Und das ist gleich eine ganz andere Ausmaß an Aufwand, Forschung, Zeit und Kosten, als der Dobrindt sich vorstellen kann. Unter Umständen werden wir noch eine öffentliche Diskussion mit den Autos (und nicht darüber) durchführen müssen, um die Autos zu überzeugen, unser Leben höher als ihr Leben zu stellen.

Und das fände ich absolut normal und wünschenswert.

Letztendlich geht es darum, eine Intelligenz auf eine billige Weise erwerben und sich bedienen lassen zu können. Das letzte Mal, als die Menschheit das versucht hat, waren die Sklaven aus der Afrika. Die damalige Vorgehensweise ist so was von nach hinten los gegangen! Und es geht immer noch massiv nach hinten los, das Ende nicht in Sicht, sehe den unmenschlichen Zustand von Afrika heute.

Ich hoffe, dass wir es nächstes Mal besser tun werden.

Service Design Fehler der Deutschen Telekom

Nachdem ich über Service Design Thinking erfahren habe, möchte ich das Gelernte auch anwenden, und ein passender Anlass hat sich ergeben: durch einen Fehler der Deutschen Telekom blieb ich 12 Tage ohne Internetanschluss. Es bietet sich, Probleme und Fehler im Service Design der Telekom zu analysieren.

Die notwendige Vorgeschichte.

Ich habe zwei Telefonanschlüsse an zwei Standorten: für mich und für meine Eltern. Ich habe beide Anschlüsse unter meinem Namen und einem Kundennummer laufen lassen, damit ich es einfacher beim Bezahlen habe und damit meine Eltern durch technische Details nicht belästigt werden. Da wir so gut wie niemals telefonieren, hatten beide Anschlüsse einen Tarif mit der Analogtelefonie. Ich habe meinen DSL bei Telekom gehabt, meine Eltern bei 1und1.

Telekom hat beide Tarife im letzten Jahr von sich aus gekündigt, weil sie ihr Netz ausgebaut haben und deswegen die Unterstützung der herkömmlichen Analogtechnik für sie Mehraufwand bedeutete. Frech so wie Telekom eben ist, haben sie entschieden, dass ihre Netzausbau (durch die sie ja mehr Einnahmen mit den Hochgeschwindigkeitsverträgen ohnehin machen) auch noch auf Kosten von den Bestandskunden gemacht werden muss. Anders gesagt, der billigste neue gleichwertige Tarif, nur eben mit der IP-Telefonie, hat mir mehr gekostet als der alte, ohne dass ich irgendeinen erkennbaren Vorteil erhalten habe.

Damals habe ich die Kröte geschluckt und einfach mal bei den beiden Anschlüssen über den Kundencenter (also online) einen Tarifwechsel durchgeführt. Ich habe einen Click and Surf Tarif bekommen, meine Eltern habe ich von 1und1 zum Telekom auf Magenta Home S gewechselt. Der Wechsel hat zunächst einmal funktioniert: bei meinem Anschluss wurde es in Januar dieses Jahres durchgeführt. Bei den Eltern mussten wir bis zum 03.07.2015 warten, wegen der Kündigungsfrist bei 1und1.


Irgendwann in Frühling 2015 habe ich mir den Auftragsstatus angeschaut und dort bemerkt, dass die Bestellung von Magenta Home S für meine Eltern storniert ist, dafür steht dieser Tarif für meinen Anschluss als bestellt, und mein seit Januar bestehender Click and Surf Tarif als gekündigt. Selbstverständlich habe ich es nicht veranlasst.

Nachdem ich die falsche Buchung im Kundencenter entdeckt habe, habe ich bei der Telekom Hotline angerufen. Ich habe das Gespräch mit den Worten “Ich habe ein vermutliches Problem bei Ihnen entdeckt” angefangen, worauf der Hotline-Mitarbeiter mir erwiderte: “Ich habe kein Problem. Sie rufen ja mich an.” Ähnlich hämisch ging es auch weiter, wo ich z.B. unterbrochen wurde mit dem Satz “Hallo! Hallo! Ich rede jetzt aber über den anderen Anschluss”. Ich habe dann trotzdem versucht, höflich zu bleiben. Letztendlich hat der Hotline-Mitarbeiter mich versichert, dass er das Problem verstanden hat, und dass er Magenta Home S wieder für meine Eltern bucht, alles Falsche rückgängig macht und ich darüber Post bekomme. Nichts davon ist passiert.

Am 03.07.2015 konnte ich Zuhause keine Internetverbindung mehr aufbauen, und diese Störung wurde erst 12 Tage später, am 15.07.2015 behoben. Ich musste täglich mit diversen Hotlines telefonieren und zweimal den Telekom-Shop besuchen, damit letztendlich die Ursache herausgefunden wurde: am 03.07.2015 wurde der DSL Protokoll von Annex B auf Annex J umgestellt. Mein Modem Speedport 221 kann zwar VDSL mit 50 Mbit/s, unterstützt aber nur Annex B.

Da das Datum der Störung exakt der “Entlassungstag” bei 1und1 war, habe ich von Anfang an den Verdacht auf die Verwechslung mit Magenta Home S gehabt und habe mich deswegen an den Telekom-Shop in Fürth gewendet. Ein Mitarbeiter davon hat folgendes behauptet:
– es wäre möglich, den fehlerhaften Auftrag ab ca. 08.07.15 schnell zu rückabwickeln. Das war falsch, andere Mitarbeiter der Telekom haben mir später mitgeteilt, dass die Rückabwicklung, wenn überhaupt, 2 Monate in Anspruch nehmen wird, oder auch nicht mehr möglich ist
– mein Internetanschluss sollte auch weiterhin mit Magenta Home S funktionieren, weil mein Modem VDSL unterstützt. Das war falsch, weil wie gesagt der Modem nur den Annex B unterstützt
– dass die technische Hotline noch am 04.07., spätestens am 06.07.15 das Problem beheben wird.

Die technische Hotline hat sich erst am 07.07.2015 gemeldet und wollte einen Termin für Hausbesuch vereinbaren. Das war nicht notwendig, weil man das Problem auch telefonisch finden kann, indem man die Marke meines Modems fragt und sie mit den Einstellungen des Anschlusses vergleicht. Dies hat übrigens ein anderer Techniker am 11.07.2015 schnell in wenigen Minuten erkannt.

Bei der Terminvereinbarung zum Hausbesuch wurde mir mitgeteilt, dass mich der Techniker eine Stunde vorab anruft, sodass ich Zeit habe, von der Arbeit in die Wohnung zu kommen. Dies ist nicht passiert. Der Techniker erschien direkt in die Wohnung, und wir mussten über meine Familienmitglieder kommunizieren.

Der Techniker konnte nicht zwischen einem Modem und einem Router unterscheiden. Bei mir sind das zwar unterschiedliche Geräte. Er hat versucht, das Telefonkabel an den Router anzuschließen. Dies ist fachlich nicht vertretbar.

Seine Behauptung war, dass entweder mein Router (wobei ich nicht weiß, ob er meinen Modem oder meinen Router gemeint hat) kaputt ist, oder meine Zugangsdaten falsch sind. Warum vor dem 03.07.2015 die gleiche Technik und Einstellungen bei mir funktioniert haben, konnte er nicht erklären, und wollte es auch nicht untersuchen. Den Ticket hat er daraufhin geschlossen.

Ich habe mich dann wiederholt an die technische Hotline gemeldet, und das Problem wieder von vorne geschildert. Die Mitarbeiterin hat sich dann auch keine Mühe gegeben, das Problem wirklich zu untersuchen, sondern hat mich einfach gefragt, was sie für mich nun konkret machen soll. Da ich damals Verdacht hatte, dass meine Zugangsdaten verändert wurden, habe ich sie darum gebeten, sie mir zuzuschicken. Sie hat dabei gesagt, dass ich dann spätestens in 15 Minuten eine funktionierende Internetverbindung habe. Nicht nur war diese Behauptung falsch, weil wie wir nun wissen, dass das Problem nicht an den Zugangsdaten lag, sondern an einem Protokollwechsel, der anscheinend zusammen oder zeitgleich mit dem fehlerhaften Auftrag passierte. Sondern auch hat diese Support-Mitarbeiterin mir die Zugangsdaten an die Telekom-Email zugeschickt, die ich nicht abrufen konnte, weil durch die Generierung der neuen Zugangsdaten meine alten Zugangsdaten ungültig gemacht wurden. Ich musste dann wieder anrufen und einen anderen Mitarbeiter die gleichen Zugangsdaten mir an eine andere E-Mail schicken lassen.

Erst der letzte von mir am 11.07.2015 kontaktierte Mitarbeiter konnte das Problem richtig erkennen. Dann hat er noch viel Zeit gebraucht, mir das Problem zu erklären, weil die Telekom-Sprache DSL Annex J als “IP-fähiger Router” bezeichnet. Router ist per Definition ein Gerät, das IP-Pakete routet, alle Consumer-Router der Welt sind insofern “IP-fähig”. Ich musste also Deutsche Telekom erst darüber aufklären, habe dabei vor lautem Schreien fast meine Stimme verloren, weil ich mich nach 12 Tagen Ausfall wirklich verarscht gefühlt habe.

Nur langsam konnte der gute Mann mir erklären, was technisch gesehen passiert ist. Allerdings war er nicht befugt, etwas zu rückabwickeln und konnte mir nur das passende Gerät (Speedport Entry) leihweise zuschicken. Und auch das geschah nicht über Nacht, sondern über den normalen Lieferweg über Deutsche Post, was weitere 4 Tage Ausfallzeit bedeutete.

Am Anfang habe ich in der Hektik noch einen Tarifwechsel von Magenta S auf Magenta M bestellt, weil ich dachte, dass das mein Problem löst und dass ich so wieder meine gewünschte DSL Geschwindigkeit erhalte. Bei der Bestellung hat der Vertrieb-Mitarbeiter gemeint, die Umstellung kann in 2-3 Tagen passieren. Tatsächlich wäre sie frühestens am 17.08, also über meinen Monat später, möglich gewesen. Der andere Vertriebsmitarbeiter hat gemeint, man kann hier nichts machen, da die Buchhaltung so schnell nicht mitkommt. Auf meine Anmerkung, dass ich für Magenta Home S wohl sowieso nichts bezahlen werde, weil ich diesen Tarif schliesslich nicht bestellt habe, hat er behauptet, dass weil es in seinem Buchungssystem steht, dann habe ich es bestellt, und wenn ich der anderer Meinung bin, soll ich mit Telekom schriftlich kommunizieren.

In der Ausfallzeit, die 12 Tage betrug und von mir völlig unverschuldet ist, war ich auf mein Handy (bei T-Mobile) angewiesen. Dabei musste ich zweimal den SpeedOn dazu buchen, weil meine Tarifgrenze schnell überschritten wurde. Keiner der Telekom-Mitarbeiter ist auf die Idee gekommen, mir auf Dauer des Ausfalls einen wirklich unlimitierten mobilen Datentarif freizuschalten. Schlimmer noch, sie haben alle meine Handy-Nummer nicht gewusst (und haben ständich versucht, mich bei meinen Eltern anzurufen), obwohl ich damals bei der Bestellung der T-Mobile SIM-Karte meine Telekom-Kundennummer gesagt habe, und obwohl der technische Support mir ständig SMS geschickt hat.

Als ich mir dann entnervt das Internet von Kabel Deutschland organisiert habe, wollte ich das Leihgerät zurückgeben und habe wieder bei der Telekom angerufen. Erst dann hat mir eine Support-Mitarbeiterin gesagt, dass die Mindestlaufzeit des Leih-Vertrages ein Jahr beträgt, ich müsste also 30 Euro dafür einfach so ausgeben. Die Mitarbeiterin hat anscheinend nichts von meiner Vorgeschichte gewusst, obwohl ich zu dem Zeitpunkt bereits alles mögliche widerrufen, angefochten und fristlos (hilfsweise zum Nächstmöglichen) gekündigt habe und der andere Mitarbeiter der Telekom versucht hatte, mich bei meinen Eltern zu finden, wohl um mich zu überreden.

Generell musste ich jedem einzelnen Telekom-Mitarbeiter die komplette Vorgeschichte neu erzählen, obwohl sie eigentlich in ihrem CRM System eindeutig stehen müsste. Es gab auch einen Fall, wo ein Mitarbeiter mir gesagt hat, dass er gerade eine andere Abteilung anrufen muss, und ich deswegen auf der Linie warten sollte, er ist gleich wieder da, dann nach 2 Minuten meldet sich eine andere Frau, sie weißt wieder von nichts und ich musste alles wieder neu erzählen.

In den Anfangstagen von dem 12-tagigen Desaster war es auch noch so, dass ich über 30 Minuten auf der Warteschleife hängen musste, bis ich durchkam.

Telekom hat mindestens zwei Arten der Hotlines, die eine ist technisch, die andere ist Vertrieb, und ich wurde von einer Abteilung in die andere, und dann wieder zurück, geschickt, weil keiner sich für mein Problem zuständig fühlte.

In der Telekom-Shop können sie sogar weniger als die Hotline-Mitarbeiter, z.B. können sie keinen Auftrag widerrufen.

Auf meine direkte Frage, ob es eine Telefonnummer für Beschwerden gibt oder ich gleich durch einen Anwalt per Post kommunizieren soll, hat der Shop-Mitarbeiter gemeint, es wüsste von keiner Beschwerdennummer.

Letztendlich habe ich alle Verträge mit Telekom gekündigt. Durch die 2-Jahres-Frist laufen sie noch bis 2017, obwohl ich seit Sommer dieses Jahres keine Telefonsteckdosen mehr habe und nichts vom Telekom benutze. Das wird mich über 600 Euro kosten. Ich war über 14 Jahre Kunde bei Telekom und ich werde niemals bis zum Tod wieder Kunde werden.

Analyse und Lösungsvorschlag

Das eigentliche Problem lag an der Verwechslung der Anschlüsse, die entweder durch einen menschlichen oder Software-Fehler entstanden ist. Durch einen guten Service Design kann man zwar solche Fehler nicht verhindern. Man kann sie aber weniger schädlich und einfacher zu beheben machen, z.B. durch folgende Maßnahmen:

1. Einfachheit schaffen. Statt mehrere Software-Systeme (Kundencenter und eine getrennte Buchungsverwaltung, wie anscheinend bei Telekom der Fall ist) soll ein einziges System vorhanden sein, so dass die Bestellungen nicht zwischen Systemen übertragen werden müssen, d.h. Übertragungsfehler können nicht passieren. Das bedeutet auch, dass die Support-Mitarbeiter denselben Online-Kundencenter benutzen sollen wie auch die Kunden (vielleicht mit etwas anderen Zugriffsrechten). Was wiederrum bedeutet, dass der Online-Kundencenter stark verbessert werden muss (Usability, Geschwindigkeit, Funktionen).

2. Transparenz, Persönlichkeit und Accountability. Bei jeder Buchung müsste angegeben werden, wer sie veranlasst hat. Sollte es ein Support-Mitarbeiter sein, müsste sein vollständiger Name da stehen. Es muss eine Möglichkeit geben, konkret diesen Mitarbeiter durch ein Online-Anfrage-Formular, oder per E-Mail, oder telefonisch zu erreichen, um eine Frage zu stellen, warum die eine oder andere Buchung gemacht wurde.

Eventuell müsste der Kunde sich dann aber trotzdem mit einem Support-Mitarbeiter in Verbindung setzen. Wenn derjenige aber schlecht gelaunt, unterbezahlt oder inkompetent ist, was dann?

3. Menschlichen Faktor ausschließen. Jegliche Vertragsoperationen (wie Widerruf, Stornierung, Rückabwicklung und Kündigung, Anfechtung sowie das Ticketsystem der technischen Kundendienstes) müssen online im Kundencenter machbar sein. Sollte es erwünscht sein, für den Kunden zu kämpfen, kann das Winback-Team den Kunden ja trotzdem nach der Stornierung erreichen und versuchen, ihn zu überreden.

Desweiteren, die Aufteilung von Telekom-Hotlines auf Technik und Vertrieb, und ein nicht funktionierendes oder nicht benutzbares (Usability!) CRM System hat dazu geführt, dass enorm viel Zeit verloren ging und viel unnötiger Aufwand betrieben wurde – weil ich mit 10 bis 20 verschiedenen Support-Mitarbeitern reden musste und keiner von ihnen konnte ausreichend viel Kontext über das Problem wissen.

4. Sollte der Kunde Kommunikation mit Menschen bevorzugen (weil z.B. der Kunde der Generation X oder älter gehört und nicht so online-affin ist), muss sie mit exakt einem Support-Mitarbeiter stattfinden. Dieser dem Kunden mit Vor- und Nachname bekannte, direkt per E-Mail oder telefonisch erreichbare und fest zugewiesene Berater soll die komplette Vorgeschichte des Kunden und des Problems kennen. Er agiert dann selbsttätig im Auftrag des Kunden, wuselt sich durch alle möglichen Abteilungen der Telekom durch, und löst das Problem.

Wenn auch das nicht hilft, soll es dem Kunden die Möglichkeit gegeben werden, die Lösung des Problems entweder selbstständig (bei ausreichenden Fachkenntnissen) oder durch einen fachmännischen Dritten herbeizuführen. Dabei ist notwendig, dass

5. Transparenz auch in (technischen) Detail vorhanden ist. In jeder Bedienungsanleitung, die einem Gerät beigelegt wird, gibt es einen Kapitel “Technische Daten”. Dort stehen wichtige Informationen darüber, was technisch (und nicht bloß in der Verkäuferssprache) passiert. Telekom sollte auch hier möglichst transparent sein. Der Kunde muss direkt im Kundencenter die neuen DSL Zugangsdaten beliebig setzen können. Er muss den Sync-Status und weitere technische Status-Informationen von “seinem” DSLAM auslesen können. Verbindliche Informationen über SIP-Proxy, STUN-Server, benutzte SIP Ports sowie die Status-Informationen müssen direkt im Kundencenter abrufbar sein (aktuell sucht man sie in diversen Foren zusammen).

Abgesehen davon sehe ich noch einen ganz anderen “Lessons Learned”. Sowohl bei T-Online als auch bei T-Mobile ist es so, dass es keine aktuell bestellbaren Tarifen gibt, die so günstig sind wie meine bisherige Bestandstarife. Tarifwechsel lohnt sich aktuell bei Telekom nicht, wenn man mit dem bisherigen Status Quo zufrieden ist. Schlimmer noch: die Konkurenz bietet die gleiche Leistung für 30% weniger Geld. Ausgerechnet in dieser Situation hätte Telekom eigentlich nur durch einen legendär hervorragenden Service ihre Kunden behalten können. Bei dem disaströsen Service, den sie aktuell anbieten, müssten sie aber mit ihren Preisen mindestens um 60-70% runtergehen (also z.B. DSL für 9 bis 12 statt 30 Euro pro Monat anbieten).

Und das ist das Lesson Learned: bei überdurchschnittlichen Preisen muss der Service auch überdurchnittlich sein. Ich nehme an, das Gegenteil stimmt auch: ein überdurschnnittlich guter Kundenservice kann die Möglichkeit eröffnen, Preise zu erhöhen.

An experience of unsupervised learning

In my previous post I’ve explained why I think you should learn machine learning and promised to share my experiences with its unsupervised part.

The unsupervised machine learning has a mystical attraction. You don’t even bother to label the examples, just send them to the algorithm, and it will learn from them, and boom – it will automatically separate them to classes (clustering).

When I was studying electrical engineering, we’ve learned about the so called optimal filters, which are electrical circuits that can extract the useful signal from the noise, even though the noise is 100 times stronger than the signal, so that a human eye cannot even see the signal. This was like a magic, and a similar magic I have expected in this case: I would pass the examples to the clustering algorithm, and it will explore the hidden relationships between the data and give me some new, unexpected and useful insights…

Today, having tried it, I still believe that some other algorithms (maybe deep learning?) are able to produce such a magic (because well, you should never stop believing in magic), but my first impression was somewhat disappointing.

The very first thing the clustering algorithm wanted to know from me, is how many clusters it should look for. Pardon me? I’ve expected that you will find the clusters and tell me, how many clusters are there in my data? If I have to pass the number of clusters beforehand, it means I have to analyse the data to find out its inherent clustering structure, and it means I have to perform all that work what I’ve expected to be performed magically by the algorithm.

Well, it seems that the state of the art of current clustering algorithms indeed cannot find clusters autonomously and fully unsupervised, without any hint or input from the user. Some of them don’t require the number of clusters, but need some equivalent parameter, like the minimum number of examples needed in the neighborhood to establish a new cluster. But well, on the other case, this still allows for some useful applications.

One possible use case could be automatic clustering per se: if your common sense and domain knowledge tell you that the data has exactly N clusters, you can just run the data through the clustering algorithm, and there is a good chance that it will find exactly the clusters you’ve expected: no need to define all the rules and conditions separating the clusters manually. Besides, it will define centroids or medoids of each cluster, so that if new, unclastered objects are added daily, you can easily assign them to existing clusters by calculating distances to all centroids and taking the cluster with the shortest distance.

Another use case would be, if you don’t really care about the contents of the clusters and the clusters aren’t going to be examined by humans, but rather use clustering as a kind of lossy compression of the data space. A typical example would be some classical recommendation engine architectures, where you replace the millions of records with some smaller number of clusters, with some loss of recommendation quality, just to make the computation task at hand to be feasible for available hardware. In this case, you’d just consider how many clusters, at most, your hardware can handle.

Yet another approach, and I went this way, is to ask yourself, how many clusters is too little and how many clusters is too many? I was clustering people, and wanted to provide my clusters to my colleagues and to myself, to be able to make decisions on them. Therefore, due to well-known human constraints, I was looking for at most 7 to 8 clusters. I also didn’t want to have less than 5 clusters, because intuitively, anything less in my case would be underfitting. So I’ve played with parameters until I’ve got a reasonable number of clusters, and clusters of reasonable (and understandable for humans) content.

Speaking of which, it took a considerable amount of time for me to evaluate the clustering results. Just like with any machine learning, it is hard to understand the logic of the algorithm. In this case, you will just get clusters numbered from 0 to 7, and each person will be assigned to exactly one cluster. Now it is up to you to make sense of the clusters and to undestand, what kind of people were grouped together. To facilitate this process, I’ve wrote a couple of small functions returning to me the medoids of each clusters (i.e. the single cluster member who is nearest to the geometrical center of the cluster, or in other words, the most average member of the cluster), as well as average values of all features in the cluster. For some reason, most existing clustering algorithms (I’m using scikit-learn) don’t bother of computing and giving this information to me as a free service, which, again, speaks about the academic rather than industrial quality of modern machine learning frameworks.

By the way, another thing that was not provided for free was pre-scaling. In my first attempts, I’ve just collected my features, converted them to real numbers, put them in a matrix and fed this matrix to the clustering algorithm. I didn’t receive any warnings or such, just fully unusable results (like, several hundreds of clusters). Luckily for me, my previous experience with supervised learning had taught me that fully unusable results normally mean some problem with the input data, and I’ve got to the idea to scale all the features to be in the range of 0 to 1, just like with the supervised learning. This had fixed this particular problem, but I’m still wondering, if the clustering algorithms usually cannot meaningfully work on unscaled data, why don’t they scale data for me as a free service? In the industrial grade software, I would rather needed to opt-out of the pre-scaling by setting some configuration parameter, in case I wanted to turn it off in some very unique and special case, than having to implement scaling myself, which is the most common case anyway. If it is some kind of performance optimization, I’d say it is a very, very premature one.

But I digress. Another extremely useful tool helping to evaluate clustering quality was the silhouette metric (and a framework class implementing it in scikit-learn). This metric is a number from 0 to 1 showing how homogeneous the cluster is. If a cluster has silhouette of 0.9, it means that all members of this cluster are very similar to each other, and unsimilar to the members of another clusters.

Least but not last, clustering algorithms tend to create clusters for many, but not for all examples. Some of the examples remain unclustered and are considered to be outliers. Usually, you want the clustering algorithm to cluster the examples in a such way that there will me not too many outliers.

So I’ve assumed the following simple criteria:

  • 5 to 8 clusters
  • Minimal silhouette of 0.3
  • Average silhouette of 0.6
  • Less than 10% of all examples are outliers

and just implemented a trivial grid search across the parameters of the clustering algorithm (eps and min_samples of the DBSCAN, as well as different scaling weights for the features), until I’ve found the clustering result that suited all of my requirements.

To my astonishment, the results corresponded very well to my prior intuitive expectations based on some domain knowledge, but also have created a very useful quantitative measure of my previous intuitive understanding.

All in all, unsupervised learning can be used to gain some benefits from the data, if you don’t expect too much from it. I think, to gain more business value, we have to make the next step and to start a project including deep learning. In USA and China it seems to be that virtually everyone is doing deep learning (I wonder if Bitcoin farms can be easily repurposed for that), but it Germany it is rather hard to find anyone publicly admitting doing this. Although the self-driving cars of German manufacturers, already existing as prototypes, would be impossible without some deep learning…

Why Should You Learn Machine Learning

In the end of 80ies and early 90ies, the topics of fourth generation programming languages and genetic algorithms were very popular in mass media. We had read in the magazines that software developers would become obsolete, because users could create their programs themselves using 4GL, or else AI systems would soon be created that would extend themselves. By that time, I’ve learned my first programming languages, was about to choose my subject in the university; and therefore had doubts about job perspectives in software development.

Fortunately (or not), Steve Jobs and Bill Gates have popularized the graphical user interfaces by around that time, so that this first AI wave calmed down (or returned to its academic roots), because software development became less about finding an answer to a question, but more about displaying windows, buttons, menus and textboxes. Computer games’ focus has shifted from “what exactly you are doing” to “how cool is looks like”. Internet has changed from the source of scientific or personal information to a ingenious marketing tool and became a thing about pictures, graphic design and neuromarketing.

But, if you are a software developer and have not yet realized that you need to teach yourself machine learning, you should be concerned about your job. Because machine learning is coming and it is the next logical step of losing the full control about your software.

First, we’ve lost the control about exact machine instructions put in our program, and gave it up to the compilers. Next, we’ve lost the control about memory management and gave it up to the garbage collector. Next, we’ve partially lost the control about the order of execution and gave it up to event loops, multithreading, lambda expressions, and other tools. With machine learning, we will lose control about the business logic.

In the classic computer programming, we were trained for the situation when the desired business logic is exactly known and specified beforehand. Our task was to implement the specification as exact as possible. And in the first decades of software development practice, there were enough useful problems that could be specified with more or less acceptable efforts. Remember, the first computers were used for ballistic calculations. Having all formulae already invented by the scientist, the programming task at hand had a perfect specification.

Now, we want to go to the areas, where creating a specification is impossible, or too expensive, or just not the optimal course of action.

We will take fraud detection as example. Let’s say we have data about payment transactions of some payment system, and want to detect criminal activity.

A possible non-machine learning approach would include establishing some set of rules for fraud detection, based on common sense. For example, some limit on the transfer sum, above of that the transaction gets suspicious. Also, transactions from different geographical locations within some short period of time are suspicious, etc.

One obvious limitation of this approach is that the alarm thresholds are based on common sense, so that the objective quality of the fraud detection is highly dependent on how good the subjective common sense of its developers reflects the reality.

Another obvious limitation of the common-sense approach is that such a rule system cannot be infinitely complex. Humans can comprehend only a limited amount of rules at once, so that they usually stop having defined 5 or 7 rules; and see a system with 20 rules as “very complex” and a system with 100 rules as “we need a whole new department to make sense what is really going on here”. For comparison, Square, Inc is using a machine learning algorithm for fraud detection based on (my conservative guess) over 3000 rules (not mentioning that they can re-tune these rules automatically every day or more often).

It is even harder for human to comprehend possible interplay between the rules. A typical geo-based rule should usually fire for distance D and time period T, but not in the public holidays season (as many people travel in this time), but even in this season it must still fire if the amount is above M, if the recipient is a registered merchant, or above the amount P, if the recipient is a private person, but it still must not fire, if the money holder had already did similar money transfers one year before and that transfer was not marked as a fraud, but it must still fire if any automatic currency conversion is taking place… At some point, a classic software developer will raise her arms and declare herself out of the game. Usually, she will then create a generic business rule engine and assert that business guys will have to configure the system with all their chaotic business rules. Which doesn’t solve the problem, just shifts it from one department to the other.

Now, remember the Shannon-Hartley theorem? Me neither, but the main thing about it was that there is a difference between the information – the useful signal that is valued by the receiver – and merely the data, the stream of zeros and ones in some particular format. The fraud detection issue can be seen as an information extraction problem. Somewhere in the transaction data, the information is hidden from our eyes, signalizing criminal activity. We as humans have practical limits extracting this information. Machine learning, if done correctly, is a possibility to extract and to evaluate more information from data.

Classifiers in machine learning are algorithms that, based on a set of features (or attributes) of some event or object, try to predict its class, for example “benign payment” or “fraud”.

No matter what algorithm is used, the procedure is roughly the same. First, we prepare a training set of several (often at least 1000, the more the better) labeled events or objects, called the examples. “Labeled” means, for each of those examples, we already know the right answer. Then, we feed the classifier algorithm with the examples, and it trains itself. The particularities depend on exact algorithm, but what all algorithms are basically trying to do is to recognize how exactly the features are related to the class, and to construct a mathematical model that can convert any combination of input examples to the class. Often, the algorithms are not extremely complicated to understand, for example, they might try to count how often one of the features appears in one class and then in another class; or they might start with a more or less random limit for a rule, and then start to move it, every time counting the number of right predictions (the accuracy) and changing the direction when accuracy is getting worse. Unfortunately, not a single algorithm author cares about the learning curve of his users so that most of algorithm descriptions include some hardcore-looking math, even when it is not strictly necessary.

Finally, a trained classifier is ready. You can now pass unlabeled examples to it, and it will predict their classes. Some classifiers are nice and can even tell you how sure they are (like, 30% chance it is a benign payment and 70% chance it is a fraud), so that you can implement different warning levels depending on their confidence.

A huge disadvantage of machine learning (and welcome to the rant part of this post): only some of the classifiers can be logically understood by a human being. Often, they are only some probability distributions, or hundreds of decision trees, so that while it is theoretically possible, for a given input example, to work through the formulas with the pen and paper and to get the same result as the classifier did, but it would take a lot of time and won’t necessarily bring you a deep understanding of its logic, so that practically, it is not possible to explain classifiers. This means, sometimes you pass to the classifier an example, where you as a human can clearly see it is a fraud, and then get the class “benign” from the it, and you, like, “what the hell? is it not obviously a fraud case? And now what? How can I fix it?”.

I suppose, one could try to train a second classifier giving the wrongly predicted examples more weight in its training set, and then combine results of both classifiers using some ensemble methods, but I haven’t tried it yet. I haven’t found any solution to this problem in the books or training courses. Currently, most of the time you have to accept that the world is imperfect and to move on.

And generally, machine learning is still in a very half-backed state, at least in Python and R.

Another typical problem of contemporary machine learning, when teaching classifiers and providing them with too many features, or features in a wrong format, the classifying algorithms can easily become fragile. Typically, they don’t even try to communicate to you that they are overwhelmed, because they can’t even detect that. Most of them have still an academic software quality, so that they don’t have too much of precondition checking, strong typing, proper error handling and reporting, proper logging and other things that we accustomed to when using production-grade software. That’s why most of machine learning experts agree that currently, most of the time is getting spent on the process they call feature engineering, and I call “random tinkering with the features until the black box of the classifying algorithm suddenly starts producing usable results.”

But well, if you have luck or, more likely, after having invested a lot of time for feature engineering, you will get a well trained algorithm capable of accurately classifying most of the examples from its training set. You calculate its accuracy and are very impressed by some high number, like, 98% of right predictions.

Then you deploy it to production, and are bummed by something like 60% accuracy in the real conditions.

It is called overfitting and is a birth mark problem of many contemporary algorithms – they tend to believe that the (obviously limited) training set contains all possible combinations of values and underestimate training for combinations not present in the set. A procedure is developed by statisticians to overcome this, called cross-validation, which increases the training time of your algorithm by factor 5 to 20, but as a result giving you more accurate accuracy. In the example above, your algorithm would earn something like 64% accuracy after the cross-validation, so you are at least not badly surprised when running it in production.

Modern improved algorithms such as random forest have a built-in protection against overfitting, so I think this whole problem is an intermittent issue of the quickly developing tech and we will forget about it in a year or so.

I also have the feeling that machine learning frameworks authors consider themselves done as soon as a trained classifier is created and evaluated. Preparing and using it in production is not considered as a worthy task. As a result, my first rollout of a classifier had produced predictions that were worse than even the random guessing. After weeks of lost time, the problem has been found. To train the classifier, I’ve written an SQL query and stored my training set into a CSV file. This is obviously not acceptable for production, so I have reimplemented the code in Python. Unfortunately, it has been reimplemented in a different way, meaning that one of the features was encoded not in the same format as the format used during the training phase. The classifier has not produced any warnings and simply “predicted” garbage.

Another problem is that most algorithms cannot be trained incrementally. If you have 300 features, have spent weeks to train your algorithm, and want now to add the 301st feature, you will have to re-train the classifier using all 301 features, even though the relationships between the first 300 features hasn’t changed.

I think, there are more rants about the machine learning frameworks to come. But, at the same time, things in this area change astonishingly rapidly. I don’t even have time to try out that new shiny interesting thing announced every week. Its like driving bicycle on an autobahn. Some very big players have been secretly working in this area for 8 years and more, and now they are coming out, and you realize, a) how much more advanced they are compared to you, b) that all internet business will soon be separated by those who could implement and monetize big data, and those who was left behind, and c) I think, machine learning will be implemented as built-in statements in mainstream languages, in the next five years.

Summarizing, even the contemporary state-of-the-art machine learning has the advantages that are too significant to ignore:

– the possibility to extract more information from data than human-specified business logic;
– as a pleasant consequence, any pre-existing data (initially conceived for other primary purposes), can be repurposed and reused, meaning extracting more business value per bit;
– another pleasant consequence is the possibility to handle data with low signal-to-noise ratio (like user behavior data);
– and finally, if the legacy business logic didn’t have quality metrics, they will be introduced, because any kind of supervised machine learning includes measuring and knowing the quality metrics of the predictions (accuracy, precision, recall, f-scores).

In this post, I’ve only described the supervised machine learning. There is also a big area called unsupervised machine learning. In December last year, at the last day before my vacations, I’ve finished my first experiment with it and this will be the topic of my next post.

And Big Data is so much more than just machine learning. It also includes architecting and deployment a heterogeneous database landscape, implementing high-performance processing of online and offline data; implementing recommendation engines, computer linguistic and text processing of all kinds, as well as analytics over huge amounts of poorly-structured and ever growing data.

If you are interested to work in our big data team, contact me and I will see what can I do (no promises!)

Beginning software architecture (for Yun)

Every programmer starts her career with something small. Implement a small function. Then implement a couple of functions talking to each other. Then implement a module, with dozens of functions, and maybe error handling and an API.

But sooner or later, we all want to move on and to step up to the higher abstraction level. We want to oversee the whole software system. We want to learn how to design it – how to do software architecture. But because this is our first time when we are stepping up one abstraction level higher, it is often very hard to do. Where can I start? When am I finished? How do I know I’ve created a right architecture?

Teachers and universities often don’t help but instead make things even worse, because they overload us with huge amount of information and detailed requirements about the architecture.

Meanwhile, there is only one thing about software architecture that is really important.

Architecting software is like caring for your child.

You want that your child will be safe and healthy; and that he will be loved, and have a long and happy life.

Safety. Your software might crash in run-time, or destroy valuable data. If it depends on its environment (other software or hardware) to run – teach your software, how to recover, when its environment fails. Teach your software, how to protect against the input from hackers and unprofessional users. Teach your software to change or produce data, only if it is fully sure it is working correctly. Teach your software, how to sacrifice one part of it to protect the whole, and teach it to run without one of its parts.

Health. Obesity is the most important problem for software. Always try to implement the same functionality with less code. Do not implement functionality, which nobody needs, but do prepare the software for the challenges it will definitely expect in the future – plan for extensibility. Use refactoring to avoid code areas that nobody is able to understand and to change, because these are the dead areas of the software body, limiting its flexibility.

Software is often created it teams. You want that the other team members love and care about the software as you do. Make sure that everyone writes code that can be read by anyone – force a uniform programming style if needed. Ensure that it is safe for team members to use the code of other team members – no unexpected results, proper error handling, consistent conventions. Avoid code ownership, because you want to get a lovely software system, and not just a set poorly interconnected moving parts.

For software to have a happy life, it must be loved and used by users. Ensure you not only understand the software requirements, but also why the users have these requirements. Work with the users to define even better requirements, which will make your software faster, slimmer or robuster. Come up with the ideas how to make your software even more lovable – a successful software will get more loving and motivating hands to work on it, while an unsuccessful software will be abandoned and die.

It is not easy to care for a child, nor it is easy to create a good software architecture. There is no rules equally suitable for all children – every time you will have to find a proper answer, may be by trial and error. But the results of the job done right might make you equally proud and your life fulfilled.

Being a happy bricklayer

“What are you doing?”
“I’m laying bricks,” said the first bricklayer.
“Feeding my family,” said the second bricklayer.
“I’m building a cathedral,” said the third bricklayer.

When I’ve learned this story in the primary school, I was shocked to see how shitty the life of the first two bricklayers were. The first one didn’t even had any intrinsic motivation to do his job, so he was probably a slave, a prisoner or some other kind of forced workforce. And the financial situation of the second one was apparently so critical that he was forced to take a job – any job he could find – to feed his family, even though he wasn’t really interested in laying bricks or perhaps even in construction works altogether.

I’m very happy to say that I was building a cathedral on every job I took so far. And frankly speaking, I don’t even see a point to do it differently. A job takes 8 hours a day. And for a hobby we could find, perhaps, one hour per day, on average? So by making your job to your hobby, and your hobby to your job, you increase the happy time of your life by 700%.

Another shocking aspect of that story is the missing loyalty of the first two workers. Per my upbringing and education, I’m normally very loyal to my employer, at least as long as they are loyal to myself. When my employer decides to hire me, they have some purpose in mind. It is the question of my loyalty, and of my integrity, to deliver upon it. But the first two workers seemed to be absolutely ignorant to their purpose in their organization!

That’s why I don’t really know what to say, every time when I hear someone declaring that his/her purpose in the company is not related to money. I mean, common, private companies have exactly one primary goal, one reason to exist: to earn money. Yes, they might have some cool vision like not being evil, or having a laser-sharp focus on perfect products, but these goals are all secondary. They are quickly forgotten when the primary goal is in danger. No company can survive for long, unless it follows the primary goal.

Therefore, I do really think that the purpose of all and every employee should be to see how s/he can help the company to earn or to save money. If s/he is not okay with that, well, wouldn’t s/he be much more happier working in a government agency, a non-government, a scientific, military, or a welfare organization?.. Just asking…

Tolles UX hat eine faszinierende (und teilweise mutige) UX. Probiert mal selber aus! Was mir gefallen hat:

1) Sie verkaufen die KFZ-Versicherung in exakt gleicher Art und Weise, wie ich es kaufen will. Es gibt keine Landing Pages mit glücklichen Menschen, die mir die Vorteile erklären. Es gibt keine Testimonials. Es gibt keine übergroße CTAs “Jetzt kaufen”. Stattdessen verstehen sie, dass wenn ich zum ersten Mal auf komme, bin ich noch am Vergleichen, welches Versicherungsunternehmen ich auswähle, und deswegen geben sie mir exakt das, was ich möchte: schnell, unverbindlich und unkompliziert mal berechnen zu können, wie viel ich in meinem Fall zahlen müsste.

2) Aber das noch nicht alles. Am Ende der Kalkulation gibt es naturlich einen CTA “Jetzt abschließen”. Wenn ich aber an dieser Stelle den Tab verlasse und mir ein Paar Tage Zeit nehme, um die anderen Alternativen abzuklappen, und dann zurückkehre, wirft mir die Seite keine “Session ist abgelaufen”, sondern sie weißt noch alles, was ich damals eingetragen habe, und ist immer noch bereit, sofort einen Vertrag abzuschließen! Das allein ist goldig.

3) Wenn ich dann bei der Bestellung an den Punkt komme, wo Zugangsdaten vergeben werden, fragen sie nur noch nach einem geheimen Passwort. Die Benutzerkennung wird dann automatisch generiert und mir angezeigt, so dass ich meine komplette Zugangsdaten in meinem KeePass abspeichern kann. Und wenn ich mich nicht täusche, wird die E-Mail erst später abgefragt, und zwar an der Stelle, wo ich selber daran Interesse habe, sie mitzuteilen (z.B. damit ich meinen Versicherungcode erhalten kann).

4) Es ist möglich, bei der Bestellung eine WerberID einzugeben, wenn ein anderer Kunde von HUK24 sie mir empfohlen hat. Es gibt aber auch einen Hinweis, dass ich die WerberID auch später (sogar nach Vertragsabschluß) eintragen kann, falls ich sie nicht zur Hand habe.

5) Wenn ich die Seite in einem eingeloggten Zustand verlasse und später einfach eingebe, bekomme ich nicht die Startseite zu sehen, sondern ein Hinweis, dass ich automatisch ausgeloggt wurde und mich wieder einloggen kann. Ich kann zwar trozdem nicht-eingeloggt weiter surfen, aber es besteht schon ein softer Zwang, mich einzuloggen. So kann HUK24 mich besser verstehen und mir personalisierte Funktionen anbieten.

6) Nach der Anmeldung komme ich zum “Meine HUK24” Bereich, wo in der Mitte die exakt 6 wichtigsten Funktionen abgebildet sind, die ich überhaupt jemals brauchen könnte: huk247) Und viele kleinere UX-Merkmale, die ich toll finde, z.B. durchgehend werden Buttons nicht deaktiviert, sondern beim Klicken erhält man eine Overlay mit Erklärung, was man noch machen müsste, usw.

Mal schauen. Wenn ihr eigentliches Produkt (die Versicherung) genau so gut funktioniert wie die Webseite, habe ich eine richtige Entscheidung getroffen.