The first dialogue with some Skeptic, or “Why is it necessary?”

Dear Reader,

to better understanding of the content of this post, you need to read the previous post on this topic: Software Development == Materialization of Ideas
(http://smartenesse.sirotin.eu/software-development-materialization-of-ideas)

But first a little introduction. In ancient times, in philosophical treatises, authors often used such a technique as dialogues with opponents or skeptics. We will use this method also. The rest of the text contains the author’s conversation with the Skeptic. Who is this skeptic? Imagine that he or she has had many years of work as an coder, tester, software architect and manager of software systems. He or she knows the problems of the IT industry as insider. He or she has already initial enthusiasm and subsequent disappointment with Extreme Programming, Cleanroom Software Engineering, Scrum and some their variations. And this experience explains his or her skepticism.

Skeptic (below S): No doubt, the thesis about the materialization of ideas sounds cool. Only here is my question: why is this necessary? Do we lack beautiful and loud statements about Scrum, TDD, etc.?

Author (below A): The branch of software development for short time had many large and small changes of paradam. They dealt with the Development Methodology (XP, Scrum, FDD, TDD, etc.), Models of the organization development process (cascading, iterative, spiral, etc.), improving the individual phases of the process (Domen Driven Design, Unit Test, Continuous Integration ) etc. Often these were breakthroughs that actually improved some parts of this complex process. But it seems to me that they all focus on individual parts. And thus the essence and meaning of the software development process eludes attention.

S: Well. The thesis covers the whole process. But what get it give for each step of the software development process?

A: For example, it may turn out that you think that you have completed a certain phase, but in fact you did not made something of the necessary or made something superfluous.

S: From this place please more in detail. And how do we find it out?

A: Firstly, you probably experienced the situation yourself, when it seemed to you that the system was ready. In one or two days it can be delivered to the customer. But new and new shortcomings are opening up. Then the Customer starts working actively with the system and opens new gaps. And when the production started, you remember that made nothing for protection your system against viruses.

S: Yes. It happens almost always. But this is a flaw in the colleagues who deal with the requirements. They simply did not catch the necessary information from the customer or forgot to write it down in specification.
A: No, it’s not so simple. They will tell you about numerous meetings with customers, application of modern review techniques, etc. etc. They asked, they registered. And in the end, the customer wanted to have some feature as in the competing system X. And often he is right.

S: Why?
A: Software industry need to get used to the idea that the times of building new systems from scratch have passed. For any important problem, there are numerous alternative solutions. And your decision should be in some sense no worse. Otherwise, the customer will not accept it. The Customer or the User expect from your system some commonly accepted level of comfort, reliability, security. The customer should not specially order them, as expected in the popular now agile approach. When a programmer buys a car, he does not even think about whether the car opens the trunk. In his own work, he expects that the Customer will specially all details.

S: So, the agile approach is bad?

A: He was and remains useful. But this is a temporary and forced decision. With the professionalization of the industry, he will fall into the background.

S: And in its place will come materialization of ideas?
A: Probably there will be new improvements in one or another aspect, which will bring new buzzwords.
The materialization of ideas as such in the software industry was in fact from the first day. Simply the further, the more clearly the understanding of this fact will crystallize, as it seems to me. The software industry by methods of work will increasingly resemble mechanical engineering or building industry.

S: But in fact the software industry differs from them in two fundamental factors:

  • In it there is no copying of one product many times (as for example in car production)
  • There is no wear and no need to replace parts (prevention)

A: Large-scale production of complex products is becoming increasingly rare. The car-buyer today can configure the car himself and thus choose one of the millions of possible variants of car. German manufacturer Audi therefore decided to abandon the traditional conveyor. Aircraft and ships are produced in very small series. And replacement of blocks on the same planes is often made not only because of wear, but because of modernization.
But it’s not about manufacturing in these industries. We are interested in the process of designing these products. There punctures, when the project phase is completed, something is not done but the developers “do not see” this, are much rarer.
As for prevention and prevention and modernization …

S: But the programs do not wear out. What kind of prevention can there be?
A: An analogue of prevention can also be found in the development of software systems. Data banks and caches should sometimes be cleaned of debris, shoveled up in traffic jams, transferring the system to new hardware.
And support and modernization requires in the life cycle of modern systems, in my estimation, about the same amount of money and time as the original development. And in this part the situation in our industry is depressing in comparison with traditional branches.
S: I think, you exaggerate. IT and its software sub-sector are developing unthinkable for other industries pace. What do you mean by a “depressing situation”?

A: I will explain this with an example from my recent practice. Once I received a very small project. It was necessary to urgently change one of the processes in a certain system. The changes were expected to be small, but they stretched from the interface to the external system through the data bank, several web services, and were eventually displayed on user web forms and support services.
S: The situation is typical. And the source codes were?
A: There were source codes stored in the version system in four programming languages, database schema and Maven – builder. And in the team there were specialists with the total knowledge necessary for understanding the code in all languages. The problem was that we did not really understand where to start, and the time-frames were as always too short.

S: It’s really a problem. I would start with a rough code analysis. By names in namespace I would try to understand which modules are interesting to us, and then I tried to catch the relevant places in the debugger or insert into the code print statements and after that to rebuild the system. And by repeating this process, step by step would come closer to the goal.
A: Here we are one. Reflecting on the plan for implementing this approach, I went to work some morning. Not far from the office I saw how for a few tens of meters before me stopped the car of the city water service. Out of him came two men in the coffins and looked around, confidently moved to the water hatch. As I come near, they opened the hatch and one went down.
“What number has it? asked the one remaining at the top. Other man answered him. The first man unfolded a plan in his hands and said with satisfaction: “That’s it. Here we…”.
I did not hear what they were going to do at this place, since I had already retired from them. But I was completely embarrassed by the shame of our industry at this moment. I thought: If the city water supply worked the same methods as us, then to search for the upgraded unit they would have to start at the water intake point and dig out the pipes until the required unit is found. But they thought about it in advance and compiled the drawings. With these drawings are able to work their specialists, including not the highest qualification.

And every time we start with code.

S: I will not hide, the analogy is convincing. It turns out, the drawings or their analogue is the key element in the thesis about the materialization of ideas?

A: First: not drawings, but the right models. And secondly: not central, but very important.
A drawing in the hands of a plumbing technician is a materialized idea of the developers of pipes, units and the water pipe itself. Perhaps it contains some information from the builders.
Our industry also requires something similar. The ideas at the beginning of the project and the program code at the end are not enough. Intermediate models are needed. The question is which models.
This is what I will try to highlight in subsequent posts in this category of my blog.

S: Well, well, thanks for the interesting discussion. I will wait for new posts.