The Role of Detailed Design
Good Detailed Design Can Expose Problems Early and Reduce Rework in Development
Recently, a junior software engineer who just started working asked me for advice on a work challenge. They received a task with a tight deadline from their leader, but the implementation difficulty was quite high. Besides the technical aspects, as a backend engineer, they also needed to coordinate with algorithm and frontend teams, which was challenging for a junior engineer. So how should one deal with this problem?
The answer is simple: Don't rush to write code, but do detailed design first.
A Concept
Before elaborating on detailed design, there's a concept to clarify:
Requirements describe what the system should be like, while detailed design describes how to implement the system. The corresponding roles are PM and RD. This statement basically defines the boundaries between roles: PM decides what the system should be like, RD decides how to implement it.
I often encounter situations where, during requirement review meetings, R&D engineers keep discussing or explaining what requirements should or shouldn't be. Although RD can offer suggestions, ultimately PM decides what the system should be like. If this boundary is blurred, discussions often become chaotic.
PM: Product Manager, RD: Research and Development Engineer.
What is Detailed Design
Detailed design is also called technical research. After having clear requirements, you need to break down the requirements, conduct technical research, and confirm the implementation technical solution. Often there will be multiple technical solutions. It's recommended to provide 3 solutions and recommend which one to choose. Provide interface protocols and database design, and preliminarily write some code to verify technical points.
Based on my past experience, here's a general detailed design template:
Background
- Description and breakdown of requirements
Technical Solutions
- Provide the advantages and disadvantages of the following solutions, and recommend which solution, etc.
Solution 1 (Recommended)
- Describe the overall architecture and implementation ideas, preferably in the form of diagrams. A picture is worth a thousand words.
Solution 2
Same as above
Solution 3
Same as above
Interface Protocol
- Interface protocols between frontend and backend, backend and algorithm
Database Table Design
- Table fields, storage resource evaluation, etc.
Schedule
- Present in table format
Risks
- List possible risks and third-party dependencies
The above content basically explains the implementation plan clearly. The schedule and risks at the end are very necessary.
The schedule is used to give an objective time estimate, with some redundancy to prevent unexpected problems that could cause blocking points.
Risks mainly refer to uncontrollable issues that may be encountered during implementation, reaching consensus with everyone.
With this assessment, if the Leader presses for an unrealistic schedule, the detailed design can serve as a scientific refutation with reasons and evidence.
After the detailed design is completed, a review meeting can be initiated. Review participants generally need to include PM, QA, and relevant R&D personnel. During the review meeting, you can present your detailed design and listen to everyone's opinions. If there are constructive opinions that you haven't considered, you can record them as Todo items and upgrade the detailed design later.
For review comments, you need to distinguish which are good suggestions and which are poor suggestions. Adopt the former and discard the latter. If there are disputes, it's recommended to think and conduct further research before reaching a conclusion. Often in reviews, there will be situations where both Solution A and Solution B are acceptable. In such cases, whoever initiated the detailed design should make the decision, as they are the person responsible for this system.
Generally, as long as a detailed design is done well, it can basically cover all requirement details, including implementation, schedule, and risks. The Leader can basically judge the implementation difficulty and manpower required for this requirement. If the detailed design review is successfully passed, then start writing code and periodically update progress in the group during the coding process, especially to the Leader and upstream and downstream colleagues, such as QA and integration parties, so they can arrange their next steps.
The Role of Detailed Design
So what is the role of detailed design? It's to secure reasonable R&D schedules, ensure R&D can work peacefully without being arbitrarily pushed by the Leader, preventing mindset collapse.
The schedule in detailed design is basically very reliable. Once during a development process, I estimated 5 days of work time in the detailed design, but one day I forgot to bring my laptop to the company. In the end, it was delayed by exactly 1 day, taking 6 days of work time.
There's a famous saying in software: "Deadline is the first productivity." This point must be evaluated when scheduling in detailed design, because R&D personnel often burst out with super strong drive and work efficiency the day before the deadline, ultimately ensuring that development can be completed before the deadline arrives and enter the next stage - testing.
For engineers who have just entered the software field, especially in the internet industry, having knowledge of detailed design will greatly improve their comprehensive capabilities.