A look at the design process

In this short discussion, I want to share my thoughts on how, in my opinion, the development process may look like. It does not matter the area in which the process is adjusted. It is quite versatile, and may be suitable for the organization of a variety of works. But the emphasis will still be on software development.

Many have probably noticed how enthusiastically they take on a new task. I want to start everything from scratch, make it perfect. But in reality this rarely happens, gradually the work ceases to bring satisfaction. In programming, this manifests itself in clutter of code, sub-optimal and undocumented solutions, increasing complexity, and it takes too much effort to keep the entire context in memory.

This is partly due to the objective cause - the growth of the system and its complication. To keep in mind all the interrelationships of a large, albeit well-designed system, it becomes difficult. But often, excessive complexity is due to a series of sub-optimal decisions that the developer constantly makes in the process of work.

An important factor in productive and quality work is the pleasure of work. The result should always like , and not only at the initial stage of the project. It doesn’t matter what stage the project is in - 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, 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, no matter whether it’s 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 elaborated 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 quality assessment. 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, the solution ceases to be pleasant to him, he does not feel pleasure from him), he brings them further to the next step of testing. And gradually, with each new round of verification, the solution is sharpened, overcomes the existing contradictions, becomes simple and clear. Experimenting with collective thinking, I came to the conclusion that to begin a constructive discussion, an initial solution is necessary, though not always (and most often) not optimal. Joint bringing the solution to the ideal is a great way to train the team, teaches people to think constructively, to see the contradictions.

I mentioned earlier 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, writing code, design, documentation) various quality criteria can be used. In addition, the specifics of the subject area can also make changes to these criteria. As well as consistent testing, quality criteria are valuable for team learning. It is unlikely that a person does work poorly from harm. Most often, poor quality is due to the 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 are too voluminous. As a result, the task begins to seem exaggeratedly important, eats inadmissibly a lot of time. And perhaps the most dangerous thing is that the developer, being too immersed in the task, misses the attention of the entire system, and this can lead (and often leads) to non-optimal solutions. Therefore, I emphasize the importance of joint task scheduling. Periodic review of tasks makes it possible not to deviate from the course, to more optimally engage personnel, to perform tasks according to their importance. In addition, planning together, each of the participants sees an integral system, is able to provide communications within it and, consequently, make the system more holistic and rational. Still, the development of information systems - teamwork.

"You can not control what is impossible to control,
and you can’t control what you cannot measure. ”

Visual control of the workflow is also an important component of a well-defined process. I am close to the Kanban methodology, 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 underlines its importance. That is, other tasks in the project depend on it. It is necessary to pay special attention when working on a task and checking it. Significance and impact on the remaining tasks are determined through joint planning.
• The gray font of the task indicates that this task is dependent on tasks that have not yet been completed.
• The background color in the "Running" column indicates the status of the task. For example, if the task for too long "hangs" on the developer (the actual execution time exceeded the planned one), this situation is signaled by a red background.
• Developers can set status to get attention. For example, "I ran into a problem" or "I found an original solution."
• In the right part in the column “Finished” the 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. It is assumed that they are used by default. And a lot has already 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 carefully it should be checked.
• Availability of quality criteria for different categories of tasks
• Joint discussion and work planning
• Visual process control