Remediation

Until now i have presented myself as an information technician of old school and provided detailed descriptions of what i think is bad practise. Let me elaborate on my approaches of remedying such problems.

Every solution is a team effort. More often than not, inefficiencies and inaccuracies are caused by a lack of communication and understanding inside and between project teams and departments. I have a vast professional background in a variety of business situations and organizational scales, including organizational and calculatory economical expertise and psychological skill, and i can bring people of various background and motivation together. I foster their mutual understanding and the understanding of their situation in a larger corporate and economical situation. For example, in „full stack“ scenarios of software production involving teams or departments of software development and operations, i can act as a „DevOp“, intermediating interests of both groups.

Every solution is a process. In today’s fragmented and sometimes contradictional state of affairs of information systems and sciences, and given the economical challenges of a free and dynamic global market, there is no single-shot remedy to a problem. Sometimes, deciders look at software and hardware components and wish for them to operate like a slot machine where you always hit the jackpot: You insert coins at the top, and your solved problem falls out at the bottom. Unfortunately, from my experience, this is rarely the case, not matter how good the quality of the product in question is. A solution has to be adopted, a technology has to be integrated. A solution has to be understood, otherwise it is not a solution but a substitute problem. This is why i do not sell standardized products. I recommend products or vendors, but if i do so, then because i have ensured that their solutions are transparent and robust under challenging and changing requirements.

Less is more. I believe to have written five hundred thousand lines of code (LOC), and that is a defensive estimate, but i take no pride in that as an achievement. Maybe, if i had focussed more, i would have achieved more with a tenth of that quantity. Today, i understand that more code means more surface for errors, portability issues, security flaws and other afflictions. As a rule of thumb, more code also means less performance, because there is more code to execute. More code means more cost, because it means more programming and maintenance hours. More code means more reading to understand what the code actually does. I think it is okay to write lots of code in order to learn what the best code for a solution is, but the code that makes it into production should be kept as little as possible. The shortening of code is a task of programming just as its lengthening is, and it should be a lauded and awarded activity. Thus i teach programmers how to optimize their code, and – if neccessary – introduce quality metrics that go beyond LOC.

Keep it simple. People strive for achievement, and sometimes they mistake complexity for grandeur, but a solution that deserves the name is less complex than the problem it solves. People strive for security, and sometimes they feel protected from challenge by surrounding themselves with complex and bureaucratic structures, but embedding oneself in such structures is a way of self-loathing and constant fear: Overall, the business suffers under inefficiency, and a suffering business is a place of constriction and dread. Being embedded in a baroque bureaucracy is not a „safe haven“, because the potential of a leaner and more feasible competition becomes the „sword of Damocles“.

Be definite. My way of work is: If you have a problem, see me. If your problem is solved, you will not see me anymore, because i am a problem-solver and not a parasite.