A look at the development process

In this short discussion, I want to share my thoughts on how, in my opinion, the development process might look like. In this case, the region in which the process is being established does not matter. It is quite universal, and can be suitable for organizing a variety of works. But the focus will still be on software development.

Many probably noticed how enthusiastically they embark on a new task. I would like to start everything from scratch, do it perfectly. But in reality this rarely happens, gradually the work ceases to bring satisfaction. In programming, this is manifested in piles of code, suboptimal and undocumented solutions, increasing complexity, and it takes too much effort to keep the whole context in memory.

This is partly due to an objective reason - the growth of the system and its complication. Keeping in mind all the interconnections of a large, even well-designed system becomes difficult. But often the excessive complexity is due to a series of non-optimal decisions that the developer constantly makes in the process.

An important factor in productive and quality work is the pleasure of work. The result should always be liked , and not just at the initial stage of work on the project. It does not matter at what stage the project is - a description of the idea or writing code, but the result should always be liked. This is one of the most important conditions for productive work.

Like - it means it has simplicity, clarity and expressiveness. And so we come to the second important component of the development process - collective checks. It seems to me the most optimal model of N checks, where N is the number of consecutive checks. Its essence is as follows. Each task is checked, it does not matter whether it is a design or the result of the development or creation of documentation. The more important the task, the more other tasks depend on it, the more elaborate and clear the solution should be. And this is achieved through multi-level checks. The first check is performed by the developer himself, so N cannot be less than 1. For this, he must have criteria for assessing quality. At this stage, contradictions can be identified that can be resolved by the developer. If there are problems in the solution that the developer cannot fix (and, accordingly, he no longer likes the solution, he does not feel pleasure from it), he takes them further to the next stage of verification. And gradually, with each new circle of verification, the solution is honed, overcomes the existing contradictions, becomes simple and clear. Experimenting with collective thinking, I came to the conclusion that to start a constructive discussion, an initial solution is necessary, although not always (and most often) is not optimal. Joint bringing the solution to the ideal is an excellent way to train the team, it teaches people to think constructively, to see contradictions.

I mentioned above that when testing decisions, quality criteria should be used . And this is the next important element in the workflow. Depending on the type of task (design, coding, design, documentation), various quality criteria can be used. In addition, the specificity of the subject area can also make changes to these criteria. As well as consistent checks, quality criteria are valuable for team training. It is unlikely that a person does work poorly out of harm. More often low quality is caused by banal ignorance of how to do it right. Quality criteria help to avoid common mistakes.

And as a separate element of the development process, I want to highlight joint work planning. Often when dividing work into tasks, some of them turn out to be too voluminous. As a result, the task begins to seem exaggeratedly important, eats prohibitively much time. And that, perhaps the most dangerous thing is that the developer, too immersed in the task, overlooks the entire system as a whole, and this can lead (and often leads) to non-optimal solutions. Therefore, I emphasize the importance of collaborative task planning. Periodic review of tasks allows you not to deviate from the course, more optimally engage the staff, perform tasks according to their importance. In addition, when planning together, each of the participants sees a holistic system, is able to conceive the connections within it and, therefore, make the system more holistic and rational. Still, the development of information systems is a team work.

“It is impossible to control what is impossible to control,
and it is impossible to control what cannot be measured”

Visual control of the work process is also an important component of a well-established process. Kanban methodology is close to me, but with a few additions. I tried to sketch out how such a Kanban board might look like:

The following notation is used here:

• The red frame of the task emphasizes its significance. That is, other tasks in the project depend on it. It is necessary to pay increased attention when working on a task and its verification. The significance and impact on other tasks is determined in the process of joint planning.
• The gray font of the task indicates that this given task depends on tasks that have not yet been completed.
• The background color in the “Running” column indicates the status of the task. For example, if a task has been hanging on the developer for too long (the actual execution time has exceeded the planned one), this situation is signaled by a red background.
• Developers can set a status to attract attention. For example, “ran into a problem” or “found an original solution”
• In the right part in the “Finish” column, tasks are grouped according to the operational plan. I really like this option, borrowed from Redmine.

In this article, I did not talk about various types of testing and the use of version control systems. They are assumed to be used by default. And quite a lot has been said about them, there is no point in repeating.

As a summary, I will list again the key points of the process:

• The pleasure of every work done, the result should be like, be a matter of pride
• N-step checks. The more important the task, the more basic it is, the more thoroughly it should be checked
• Availability of quality criteria for different categories of tasks
• Joint discussion and work planning
• Visual process control