What programmers get from design?

Question

We can all write program code and just develop a solution in our heads. Also, when we maintain existing code, we can see the design from the code if it is well written. Many people see documentation as an unnecessary burden, which basically causes additional work, because the documents also need to be updated.

Another option is that we first create project documents, then program the solution in accordance with the project, and then continue to update the documents. We could use a separate constructor to create project documents, or we can develop it ourselves.

What programmers get from design? Or is everything all right and start programming without separate project documents? What are the design documents needed for a programmer's perspective?

Answer 1

For any, but the most trivial software, you must make a preliminary design, otherwise you will either

A.) Get on your ass B.) You have buggy software C.) You have a serious refactoring problem later

In my opinion, the human brain is silent about facts that it does not want to cope with at that time. In the case of software development, I always develop in advance to make sure that I have something on paper that I am sure will work and will be optimally concise, functional, extensible, etc.

Answer 2

Programmers require at least some information before they can start a project, whether this is in the form of project documentation or through direct contact with people who need software, is obviously debatable.

I am in a busy camp where people and interactions prefer the process and documents. However, I am also pragmatic, which means that if you do not have access to business or product owners, you must, of course, work on some kind of design. But I will always maintain personal interaction with documents.

From a flexible point of view (depending on your taste), the documents will be in the form of form cards that represent individual functionalities that will be developed, and when this functionality is considered “done”. The specific details of what is developing, however, come from interaction and communication with the business and will, in most cases, be formed through “evolutionary” design.

Although it is true that documents can be updated, and yes, sometimes this happens, I find that in most cases this is not so. You also face version nightmares, developers working with the wrong document, or QA testing of the wrong version. It is a simple fact that in a rapidly changing business situation, as soon as you record it, it becomes obsolete.

Most of the problems are unknown during the design process and are detected through the actual development process, so it makes sense to invest more time and effort on the development stage than to spend it on the design stage, where there may be assumptions and it will be wrong. You CANNOT design for something you don’t know! The sooner you enter and discover these unknowns, the sooner you can develop your design to meet new requirements.

Answer 3

For (very) small projects, programmers can do without much planning ahead of time. However, the larger the project, the more important the foreground becomes.

You can build a dog house without too much planning, but imagine how to build a skyscraper without architectural plans.

Large projects built without prior design quickly degenerate into masses of unreachable code.

Answer 4

As with the cases mentioned above, design, such as a class diagram, can help you get the big picture. As your project gets more classes or modules, their roles may begin to become fuzzy, and the temptation is to simply break things down everywhere. Keeping the project up to date can help reuse the intended roles and help the programmer place things more appropriately and avoid overly complex and possibly circular dependencies. Similarly, a flowchart can help us focus on how parts should interact.

Answer 5

I believe that project documents are necessary. One reason for this is that you don’t have to spend so much time introducing a new member to the project by letting him read the code. Instead, a new member can quickly look at the design to get a big picture.

Another reason is that if you do your project in advance (do not forget to repeat the iteration), you will most likely find many errors at the design stage, which is less expensive to “repair” than if you find it at the development / code stage . You are more likely to find better solutions to your problems if you develop advances (with iterations). It’s easier for me (in my opinion) to get a colleague / project member to consider your work if they should not read the code, just a design document (UML diagrams, etc.).

Answer 6

If you expect to finish quality software on time, you will need to get some requirements on paper before coding begins. For business applications, writing every detail and confirming it with the help of domain experts avoids wasting time because programmers made the wrong assumptions.

Answer 7

The mistake made by inexperienced programmers is to neglect part of the design. They think this is a lost time, but it is not. On the contrary!

A good design reduces the lot by then. Including error detection.

Answer 8

Do not allow "architectural documents" for "design documents".

As indicated in this question, design is what is required to implement architectural solutions, which can be specified as a specification document at the business or application level.

When it comes to the technical level, you can create “design” documents (for example, UML diagrams), but they need to be constantly synchronized with development, which can be difficult to do.

The usual “project documents” that I see are class diagrams that are retro-linked to code.