Software-System Technical Planning Methodology

1. My Understanding of Software-System Technical Planning

As the name suggests, software-system technical planning means making technical plans for a software system. It can be described in three parts:

1. Software system.
2. Technical side.
3. Planning.

1.1. Software System

At a large scale, desktop PC software, Web pages, mobile apps, and so on are all software systems. At a smaller scale, a service, module, component, or small tool also belongs to the category of software systems. Any software system can be technically planned. On one hand, no perfect system exists; there will always be one problem or another. By attributing and classifying those problems, we can make a plan. On the other hand, everything in the world keeps developing. Even if the current system were truly perfect, we could still think about its future direction and conduct technical exploration, innovation, or even disruptive change around that direction. This is also a kind of planning.

1.2. Technical Side

The technical side is relative to the business side. Although this note focuses on the technical perspective, we should also know that technology and business complement each other and cannot be viewed in isolation. Business development gives technology a place to be useful, while technical support allows the business to develop better. Therefore, technical planning cannot avoid business topics.

1.3. Planning

According to the definition of planning on Baidu Baike:

Planning is a relatively comprehensive and long-term development plan made by an individual or organization. It is thinking and consideration about future overall, long-term, and fundamental issues, and the design of a complete set of future actions.

In my personal understanding, there are two key points:

1. Planning is a solution.
2. Planning is a plan.

1.3.1. Planning Is a Solution

A solution is a measure used to solve a problem. Therefore, a solution must clearly state what the problem is, avoid empty grand statements and castles in the air, and be detailed down to how the problem is solved, or the concrete steps for solving it.

Saying that planning is a solution means that planning must also satisfy the above requirements. At the same time, compared with an ordinary solution, planning first focuses on solving fundamental problems rather than one or two bugs. Second, as the saying goes, one who does not plan for the long term is insufficient to plan for the present, and one who does not plan globally is insufficient to plan locally. Good planning needs to switch from a local perspective to a global perspective and propose solutions from a relatively comprehensive, overall view.

1.3.2. Planning Is a Plan

1.3.2.1. Planning Faces the Future

Planning mainly faces the future, but to look ahead we must first stand on the present. For a software system, we need to understand the current state and even its past evolution well enough before we can make a good plan.

1.3.2.2. Planning Is Long-Term

How far into the future should planning look? Generally 3-12 months. If it is too short, rushing to delivery may create many bugs, and nobody wants to live every day under the fear of deadlines. Too long is also not good: plans cannot keep up with change. If unexpected conditions make the results fall short, a smaller ship is easier to turn around.

1.3.2.3. Planning Must Be Scheduled and Delivered

Planning needs to be executed. Put simply, it needs a schedule: a certain function should be completed at a certain time.

1.4. Summary

1. Systems of any size can have technical planning.
2. Technical planning cannot be separated from the business perspective.
3. Planning is both a plan and a solution. From these two points, the planning methodology naturally follows:
   1. Organize the past/current state.
   2. Look to the future and propose an ideal state.
   3. The gap between the past/current state and the ideal state naturally reveals fundamental problems.
   4. Design solutions for the problems.
   5. Schedule the work and implement the solutions.

2. Why Do Planning?

Everything needs planning. At the national level there are five-year plans; at the individual level there are life plans and career plans. In my understanding, the biggest benefit of planning is having goals and a sense of direction. With goals and direction, we are less likely to feel lost and can apply our effort correctly. Energy only produces twice the result with half the effort when it is used in the right place.

The same principle applies specifically to software-system technical planning. With a plan, we can steadily build a system that is friendlier to users and may even become an industry benchmark. There is also a more practical reason: for a programmer, planning ability is necessary for further growth and is a required skill on the path toward becoming a senior engineer.

3. How to Perform Technical Planning for a Software System

3.1. Collect Materials

Collecting material runs through the entire planning process. Only with enough input can there be output. Materials include, but are not limited to, code, previous planning documents, technical proposals, integration documents, and so on.

3.2. Organize the Current State

Start from two directions:

1. Business functions.
2. Technical architecture.

3.2.1. Business Functions

We can actually experience the system from beginning to end, understand what roles it has, put ourselves into those roles and operate the system, and finally produce an integration document.

3.2.2. Technical Architecture

While experiencing the system, use traffic capture, logs, code reading, and other methods to organize the system architecture and critical paths. At minimum, summarize these two diagrams:

1. Layered architecture diagram.
2. Critical-path diagram.

3.3. Look Ahead and Propose the Ideal State

There are two ways to infer the system’s future:

1. Induction.
2. Deduction.

3.3.1. Induction

We can research competing products, understand how similar systems inside and outside the company are built, organize and summarize them, and compare them with our system to determine what needs to be done in the future.

3.3.2. Deduction

But what if competing systems have nothing worth learning from? We can start from first principles: think about what the system fundamentally is and whom it serves, then use logical reasoning and evolutionary thinking to derive its future ideal state. This is similar to how this note started from the definition of planning and derived the methodology for doing planning.

3.4. Discover Problems

What is a problem? A problem is the gap between reality and the ideal. If the current state and the future ideal state described above are already clear, discovering problems becomes straightforward. Specifically, problems can be summarized from areas such as:

1. Technical architecture.
2. Integration efficiency.
3. Performance.
4. Stability.
5. Cost.
6. …

Efficiency, performance, and stability problems at each layer.

3.5. Design Solutions

For one problem, we need to propose at least three solutions, summarize the advantages and disadvantages of each, compare them, and choose one. Finally, for the selected solution, summarize two diagrams:

1. Layered architecture diagram.
2. Critical-path diagram.

3.6. Schedule and Deliver

Once the solution is ready, the remaining work is to schedule and deliver it: list the TODO items, sort them by priority, and complete them one by one.