You may ask yourself from time to time why you are actually working in a "team"! Everyone is working on the same software, but somehow it's every man for himself. Everyone builds their part of the system, occasionally with support or perhaps in pairs. Structures grow organically with every built-in feature. You know your part of the system, hopefully you don't have to work on the rest. I assume every developer is familiar with this way of working. What's more, it's the familiar picture.
I advocate a different approach in the team, in the department, in software development in general. I advocate designing a solution before implementing it. And that in a team. The team is the ideal starting point for Flow design drafts. The joint design phase has an impact not only on the quality of the solution, but also on the entire working method.
Advantages for the source text
I'll start with the obvious advantages.
Responsibility! A magic word among the principles. SRP and IOSP, for example, deal with this and are the foundation of good code structure. I often hear and share the experience: "I write the solution first, no matter how. Once it's up and running, it gets tidied up". It can easily happen that mixed responsibilities are overlooked. In the joint design, we can apply the principles even before the actual programming. Different aspects are quickly recognized and separated before implementation.
Structure! If we design a solution before we implement it, we already have a structure. During implementation, we don't have to think about which classes we need, whether they are complete in their current state or whether a different name makes sense, whether they are static or hold state... all of this has already been planned. In the team. Classes, methods, state variables, parameters, everything we need is known. The structure is in place, we just have to write it down and can concentrate on the technical details. It's almost boring.
Tests! If we're going to write it off, we might as well do it right. Test-first? No problem. The design provides us with the signatures of the required methods, data structures and classes. The perfect template for a test suite. We can put all classes and methods under test before we write them ourselves. So we have to worry much less about tests.
Readability! Is teamwork. If we work together on the development of methods and classes, an appropriate name usually develops. A developer alone sometimes lacks the inspiration for a method name. Discussions can and should take place within the team until everyone is satisfied. The flow design draft promotes readable signatures. The solution path is separated from the implementation details. The focus is on what a method does, not how.
Consensus! Have you ever looked at code from other developers and at least cursed inwardly? About the type of solution, the readability, the structure, the interfaces or the tests? Many roads lead to Rome, but some are rocky. Drafts help to find solutions together. Every discussion contributes to the final solution. Any disagreements that arise can be negotiated along the way. The quality of the solution increases on the one hand, and acceptance increases on the other.
Advantages for working in a team
Let's assume that we are a team at the start of a sprint. We have our catalog of requirements that should ideally be completed by the end of the iteration. What are our options? Everyone could work on a requirement alone or in pairs. The alternative is for everyone to work together on a requirement and work through the catalog piece by piece. And yes, you can work on a requirement with four people. Drafts form the basis for this.
Contracts! Once we have designed a requirement, we can create contracts for the resulting data and class structures. We can provide a package that contains the data structures. In addition, we extract interfaces from the designed class structures and methods.
Work organization! With the design and associated contracts, the work for a requirement can easily be distributed among several developers. Using the contracts provided, each developer can implement their part of the requirements independently of the others. Distributed implementation, including tests of course. Subsequently, all parts - and here's the highlight - are easily(!) merged and integrated.
Scalability! Results from the two points mentioned above. Imagine you have a requirement that has a very high value for the product owner. It should go live as quickly as possible. Sacrificing quality is not an option and usually does not speed up the process. So the process has to be distributed. A trained pair is faster than one person alone. So why not put four or more people on it? Parallelization certainly has its limits, depending on the size of the requirement. But it is worth pushing this limit.
Clean code training
Closed company courses
We conduct all seminars as closed company courses for you.
If you are interested or have any questions please contact us.
Advantages for the distribution of knowledge
Domain knowledge! Everyone involved in designing a solution is then familiar with the solution and the requirements. Regardless of whether they are involved in the actual implementation. Unknown spots in the software are minimized, knowledge of the domain increases. The result is greater familiarity with the whole thing with the same amount of work for each individual. If there is a change of personnel in the team, knowledge of the domain is not immediately lost. We gain greater reliability.
Domain language! Shared communication about the domain promotes the development of a domain language. The vocabulary develops and is used. This is reflected in the source code and in the exchange of information. A common understanding grows and spreads. Domain Driven Design uses the term Ubiquitous language or Ubiquitous Language. And it is precisely this that is developed in design phases and translated into source code.
Code knowledge! The implementation mirrors the design. This principle must be adhered to. It guarantees that the knowledge acquired can be found in the code. There are numerous situations in which a developer works in someone else's source code. If he was involved in the design for this implementation, he will find his way around the source code and feel comfortable with it. The code base is an open book. This results less in: "Oh, I don't even know this stuff and now I'm supposed to jump in here?" and more in: "Right, that's how we solved it. Well, then I know where I can continue." In the code review, explicit attention should therefore be paid to whether the principle has been adhered to.
Communication! Working together promotes communication. In my experience, there are developers who have a pronounced tendency to avoid communication. Especially when they are working on a solution. I count myself among them. Puzzling and puzzling over a solution has made me hesitate at times to share the problem with someone else at an early stage. Even when I was stumped, it seemed more obvious to research until I found a way than to inform my teammates. The result was often a success that took more time than necessary. Sometimes a failure that I made public much later than would have been good. Such really unpleasant situations arise much less frequently when the solution is discussed together. The puzzles in the implementation of a design are clear. And if a hurdle does arise during implementation, you can call the team together and refine this part of the design again.
Continuous improvement! Drafts contribute to continuous improvement. Developers with little experience benefit enormously from being involved in the solution process. Whether in training, with two or ten years of experience, everyone learns in the design phases. This is noticeable. Over time, designs become faster and easier. A trained team develops standards or patterns, certain procedures for certain challenges. These patterns become ingrained. Working together to develop a solution for a complex requirement also becomes engrained.
Receive an excerpt from the book "Mit Flow Design zu Clean Code".
Conclusion
A Flow design draft helps to create a good solution for a requirement. The design phase as an integral part of the development process, especially in a team, offers so much more. The work in the team changes significantly. The design brings structure and quality to the source code. The design phase brings structure and quality to the team. Sounds good? We think so too. That's why our open training course Clean Code Developer Advanced precisely with this topic.
English 
German