Architecture

How a developer can tell if the system is sick just by taking a look at the input and the output? If you’d like to know that (plus you like standup comedy), come and see! The treatment is safe ;-)

One approach to get familiar with a system is a long and intense reading the manual (and to run an eye over the source code sometimes). Another approach is to take a deep dive into the data model (often in the DB) and to surf the user interface. Both are natural ends of the system, the legendary Input and Output. By examining these ends one can check if there’s good digestion or if guts are rotten. Careful examination can confirm “common DDDosis”, “malignant stringosis”, “regex diarrhoea” or “not-made-here syndrome”. Unfortunately, sometimes developers get infected in their prenatal life (meaning: at their university). Let me invite you to treatment. A laxative one. (That is: a sequel of “Passwords. Do you keep them safe?”)

“The best sorting algorithm is quick sort.”
“Indexes make DB faster.”
“Data should be sorted using ORDER BY.”
“Composition - good; inheritance - not good.”
“Windows is an operating system.”
“You must have transactions in your DB.”
“Java is slow.”
“Don’t eat yellow snow.”
“You shall not self-sign your certificates.”
“Interrupt in Java is broken.”

The IT world is full of mantras/revealed truth, passed (often in oral tradition) among developer tribes. Mindlessly repeated from generation to generation, they cause a reckless usage. At best this results in more harm than good, in the worst case: a total disaster worth whole train of money. The context is indispensable part of each mantra. Right context can help to distinguish proper usage from incoming disaster.