Software development cannot be likened to architectural development

Over the years, the software industry has been using an analogy, that is, the construction industry to do the reference and metaphor. This comparison is common in software languages such as architecture (architecture), foundations, Builders (constructor), Projects (project), Construction codes (building code), and so on. These claims are so popular that it affects our understanding of software development. Unfortunately, this metaphor is fundamentally inappropriate, and its flaws have led us to some of the wrong ways.

　　

In the construction industry, much of the focus is on predictability-defining requirements in advance and cutting costs. These are the hallmarks of a mature industry. And when we apply these priorities to the software, the problem comes!

Rules of thumb, construction codes and raw materials

Modern architecture can be traced back to hundreds of or even thousands of years ago--it depends on where you put your starting point. After all the history of precipitation, a lot of expertise is condensed in the rules of thumb, such as:

In most places, the cost per square foot of construction is a well-known constant. For example, we recently made some renovations at home, and friends in the industry reminded us that the typical refurbishment cost in Ottawa is between $ A square foot and $ A. They're very accurate!

A good estimate of the depth of the cement floor is equivalent to 1/180 of its non-supported circumference.

Software, on the other hand, has a history of up to 70. Its rules of thumb have not been as solid as the architecture of history, and are not yet sufficient to guarantee indestructible applications.

The rules of thumb will eventually be compiled into construction codes and solidified. When building a house, the construction code determines everything from the spacing of the walls to the amount of insulation on the walls and roofs. These specifications mean that all houses meet the minimum requirements and greatly increase the predictability of the cost.

The existence of these construction codes is mainly due to the limited variety of building materials (wood, steel, etc.) and tools (hammers, saws, etc.). The properties and failure models of these materials are predictable. The few tools that can be used in conjunction with specific materials have been fully recognized. Of course, in the construction industry, materials and tools continue to evolve, but they evolve much faster than software.

In the software industry, it's much more difficult to keep up with a range of new materials and tools! Programming languages, libraries, support tools come out every year and evolve constantly. The content is also constantly enriched. Even if we focus on existing languages and libraries, it will take years to explore all the details and understand the nuances in order to develop standard specifications.

It is the easy-to-understand, stable materials and tools that make building codes possible. The instability of the software world determines that we will never have a "construction code" in this field.

There is no useful rule of thumb or construction code in the software industry!

Physical constraints and the need for stability

Buildings, bridges and other building fortifications are governed by physical constraints. Depending on the material used, these constraints determine the size, shape, and purpose of a building. For example, wood-frame construction is limited to the height of the 4~6 layer, the span of the bridge is limited by the materials used, and the physical properties associated with these materials.

Buildings and bridges represent a problem area that has been studied and experimented on for generations. Therefore, the customer needs to ask questions are predictable, the scope of the answer is also constrained.

Architectural design must be adapted to the site and function constraints. Imagine building a tower around a single-point rotating gyroscope, which, while interesting, is physically impractical and unable to meet functional requirements. When building bridges or highways, there are clear standards to follow, depending on the type and size of vehicle to be borne.

And the software is not subject to similar constraints. If the customer really wants something like a gyroscope, we'll probably be able to deliver it. The types of users we need to support and the uses that are much broader than buildings!

Once the building has been built and the foundation is in place, you cannot easily change the size or location of the site. Once the building's interior is built, you can't decide to add an elevator shaft or a flank. When building bridges, once the piers have been poured, you cannot move them 20 meters because the customer has chosen the wrong place. (OK, you can, but the work before this is wasted, you need to start again!)

And for software, we can almost do whatever changes we want, simple or complex, such as raising the number of supported users from 100 to 1000, changing the direction of the product (Yelp was a tool for recommending restaurants, doctors, etc. to friends). Later evolved into a review site), in a different programming language (I've been involved in projects that have changed from Java to. NET and back to Java)--all these changes are much smaller than the cost of starting over again!

Note: Yelp is a famous American merchant review website, founded in 2004, including restaurants, shopping malls, hotels, tourism and other fields of business, users can be on the Yelp website to the merchant rating, submit comments, exchange shopping experience and so on.

Because we have great flexibility in software, we are also able to accept changes in demand throughout the development process. The need to exploit the early stages of development is often changed several times before they are finally realized.

In the world of architecture, when designers give a set of drawings to the builders, there is considerable confidence that they can understand them correctly. Although there will still be some changes in demand and communication, but the degree of change should not be the same as software. In the world of software, we don't have an effective way (even UML) to deliver a design to a developer and then we can do it. Instead, we have to continue a series of meetings between our customers and software developers.

Software is more inclined to accept drastic changes than architecture!

Personnel

In the construction industry, workers are often considered to be interchangeable and replaceable. There is a hypothesis that if you replace a carpenter when you build a house, the result is usually the same.

This is not the case in the software world! Because of the complexities and variables that exist in tools (programming languages and libraries) and problem areas, developers, business analysts, testers, UX designers, and others cannot flow anywhere.

Those who think that software is associated with architecture assume that people can be replaced and exchanged. But that's a far cry from the truth! All the substance of the software is built by people on each team, and if you replace a team member, it will affect the team in the following three main areas:

They will lose the knowledge that only the former team member knows;

They must train new team members: What they are doing, and the latest progress;

They must take the time to establish effective working relationships with new people.

As a result, replacing or adding a new person slows down the team's progress by at least 3-4 months. In the case of cases, new team members often spend longer than they do before they are fully effective. While the construction industry suffers from delays in personnel changes, it is far less painful than software projects.

Fred Brooks (the author of the man-month myth) has a famous saying: "Adding manpower to a project that is lagging behind will only make progress more backward." "More than 40 years later, that sentence still works!"

Conclusion

Architectural metaphors that are often used to describe software are wrong. Sadly, because of this hint, we put a lot of emphasis on the wrong place:

Strive to define the needs clearly, not accept: change is the norm;

Emphasize the importance of architecture and architects rather than acceptance: software is adaptable and can be changed by anyone on the team;

Suppose the person is replaceable, and the time problem can be solved by increasing the number of people, rather than accepting: everyone is unique;

The pursuit of predictability, not acceptance: Our field has not been well recognized.

Software has nothing to do with architecture!

We are not building, we are exploring!

We explore in the customer's problem space. We're proposing new ideas, and they're just going to be expressed in code. Let us discard old architectural metaphors, because they will collapse the foundations of our path to the future. I'm not the only one who can hold this view!

Software development cannot be likened to architectural development