Lubo Drobny

It is quite annoying to me when argument during discussion is like this:  it must be XY because the book says it. It is kind of: Bible is saying XY so we have to follow = end of discussion.  I am not very happy in such a case because we probably do not understand principles and just trying to blindly imitate something without deep knowledge of the matter. I prefer to admit it or show personal standpoint.

It is absolutely normal to invest time & money into cleaning service, so working desks, floors or toilets are clean and tidy. Working in messy environment is not easy and productive. Find a pen on table covered by tons of papers, gadgets and books can take few minutes instead of 1 second when it is just there. This makes sense for everybody. But when we talking about cleaning & tidying = refactoring of source code it is not so obvious and some managers suddenly needs SWOT analyses, meetings and arguments to understand why we should invest into it. The reason is very simple: what is business value of refactoring? Product management do not see any new feature (it was working before) but only risk of regressions. Also they have feeling that we did tons of shortcuts & dirty hacks till now so one more cannot hurts. Let's ask another way: what is business value of cleaning of working desk? Mainly: better, faster & comfortable work. Is is not directly linked with bu

Almost everybody in IT knows 'Answer to the Ultimate Question of Life, the Universe, and Everything', it is 42 - according to Douglas Adams book, but who knows the question? It is just joke from the book but anyway makes valid point. Good questions are important. From my coaching experience I can confirm it. People appreciate when I am asking good questions which help them to think different way or change perspective. They feel that in many cases it is more helpful than direct answers because they are able to figure out solution themselves. It is process of learning principles and getting fluency. It is obvious that non-directive approach needs time. It would be crazy to do it in critical or very stressed situations where direct answer do the job right.

Software engineers are very often pushed to implement solution which consumes less effort instead of the right one (clean and well designed). It is short term thinking: now we do it 'quick & dirty' and maybe later we will make proper way, which usually never happens. Common reasons for this decision are: time to market, nervous customers, release deadline, it is 'mess anyway' or manager's bonus for 'green' excel. The final result of all these quick hacks and dirty workarounds are accumulated in technical debt, which we would have to pay to make it right. Critical amount of technical debt is illuminated by classic symptoms: maintainability is very low factoring of code is awful (spaghetti) ownership of code does not exists unit tests are just fake or joke static code analysis is rather turned off CI is unstable and very slow (CD is only dream) adding new features is very time consuming  estimations are just guess from magic ball architect