Why is the system optimized?

Let me tell you a story: when I went to college, I took a "advanced" Object-Oriented Programming Course. I have never been involved in this field before. This course uses the Smalltalk language and has a special teaching method. On the first day of the class, the professor assigned us an assignment that will take four weeks of the course.

We are all very excited because we want to write a game. An adventure game similar to Zork text input. We joined a group of three in the crowded hut of the professor. Descriptions of game requirements are on a simple page. We almost ran away.

But when we were about to go out, he called us back again (I believe he chose this opportunity ):

"Oh, by the way, I almost forgot! Two weeks later, I will adjust some basic content of the game. You need to continue after the adjustment ."

I have told this story many times to many development teams (including the founders of some products). Their responses are almost the same:

• Laugh, or at least giggling, and often hear "pfffft.
• Oh, my God, this is too boring.
• How strict a professor-this is simply an impossible task

The problem is that the professor did not tell him what changes he would make. It's just that something will be modified-two weeks later.

How do you think we should complete this task?

We provide defense everywhere during development.

• "Oh, no.-What should I do if the professor intends to change this ?"
• "Maybe we should make this an interface -- what if the professor asks for different ways to implement it ?"
• "No -- we should extract this part. In this way, when we modify this part, we do not need to change module X"

This is our practice. What I want to talk about most is that this is a very good job task, which has taught me a lot in Object-Oriented Programming and smalltalk. Thank you, Professor David son!

Finally, we made a very modular system, which made it easy to modify them. When that day finally came, after the game design was modified, we tried to modify the program as required within one day, so that we can smoothly develop the interface and monsters and other cool parts.

We optimize the system for future changes. Because Professor David son told us that the change will soon come.

Let me tell you a story about a system developed about 25 years ago. It is an important business system of a Swedish company. I said this is an important business system because it processes 80% of the company's revenue.

From the very beginning, they thought about everything and kept extremely detailed documents. They also developed a set of strict demand change specifications. They want to avoid changes in such a system as much as possible, because there is a high risk that an error may cause a huge impact.

The company is so worried about such a problem that they have written a series of measures to prevent system problems; all the code should be commented out by a second person without the original code author. In addition, the test cannot be executed by the Code creator.

Similarly, various risk management measures have been developed to control the formulation of Software specification documents. The person who writes the specifications is divided into several levels to ensure that they are inspected layer by layer before being submitted to the relevant IT business department.

Over the past 25 years, these departments are still busy preparing documents and managing risks. This solution has few problems, but is very inefficient. A change may take about 30 weeks from being included in the plan to being submitted to the product. One idea should be officially written into specification documents and approved by more than 20 persons of different levels. Programmers who hold such instructions call themselves "constructors" because their actual job is to translate pseudocode into the COBOL language.

All things around this system aim to control risks and demand changes, and put stability first. They think that any modification will generate an accident. But unfortunately, the only thing that can happen to a business is change. And the frequency of changes increases.

They optimize the system for stability.

I would like to emphasize that, in the second story, people with such ideas do not take a minority in their lives. They are excellent people, but they are arranged to develop a system with stability as the first priority. This is the real risk.

Conclusion

These two stories Let me think a lot:

• What is the purpose of optimization when I write code?
• Changes always come. I knew it from the very beginning. "During the 25 years of operation of this system, I will constantly modify its specification ". How can I deal with such a problem?
• How do I view changes as risks? Or is it a driver? Quick response to changes is a commercial advantage and a good way to control risks. How can I make my code easier to change?
• In a system that will carry out a large number of modifications, what kind of documents can satisfy me?

What are your goals for optimizing the system?

Address: http://www.marcusoft.net/2013/04/WhatDoYouOptimizeFor.html