David Lorge Parnas: What exciting software engineering technologies do you think will emerge in the future?

David Parnas: The most useful technology is not in the future. It’s been around for years and we’re just not using it.

Many students learn some programming languages, read some tech blogs, and are generally enthusiastic. They do a project and they want to show what they’ve learned.

Add cutting edge technology to make a sensational innovation. This is to be encouraged, but practice has shown that it often fails.

Let’s look at some successful examples of what they did, like when Linux was first developed:

I’m doing a (free) operating system(just a hobby, won’t be big and professional like GNU) for 386(486) AT clones.

I am writing an OS for the 386(486) AT Clones (just a business hobby, not as professional and huge as GNU).

Those entrepreneurs who start out with the idea that they’ll make it big-can be guaranteed failure. — Peter Drucker

Entrepreneurs who start out thinking they’re going to be big are bound to fail.

preface

As I begin this article, I think of my junior high school. I went to school in town and went home once a week. I always confidently set a goal to go home and read all the books I had memorized. But you know how often kids can’t resist temptations like sleeping in and playing games. When I woke up, my little friend came, and then we went to play games. When I go to school again, I will carry these books to school. This repetitive work should have lasted through my junior high school years. Back to that time, back of the book the goal of this no reason is I set too big, let me find it hard to finish, but at that time I didn’t realize this, obviously every weekend, I will desk full of books into the bag, I was delighted, fantasizing about yourself at home reading will make the family happy.

Then I remembered the project competition in my university. The project leader wanted to build a beauty makeup community mall, which was roughly equivalent to the combination of Xiaohongshu and Taobao. I introduced our technical background at that time: Servlet, JSP, JQuery and MySQL(basic SQL statement writing). But at that time did not complete small red book add taobao combination of design goals! Our goal was to build a building, and we ended up with a ramshackle thatched hut, just waiting for “The wind to howl in August” to “roll my house on three grass”.

I think there’s always a sense of fear when a goal is too big. The conventional wisdom is to break a big goal down into smaller, seemingly manageable goals.

I think it’s nice to solve big problems, but it’s not easy to really solve small problems.

On the principle of software design

The requirements that people encounter in practice are constantly changing, and many principles of software design are derived from practice to ensure the maintainability and efficiency of programs in the face of changing requirements. Let’s take two software design principles as examples. First, the Single Responsibility Principle (SRP) states:

A module (class) should have only one cause for its change, and a module should be fully responsible for a function.

The classic book on software design, Agile Software Development: Principles, Patterns, Practices, includes the following examples:

A module dealing with squares has two functions: ① calculate the area and ② draw the square.

This design gives one module two distinct responsibilities: performing geometric operations (independent of the display) and graphically drawing squares. If a collection computing program needs to use this module, it will need to include the graphical display part as well (because it is in the same module), which is wasteful and introduces unnecessary dependencies (because the graphical display is related to the graphical underlying implementation), hindering portability. In addition, changes in geometric calculation requirements and graphical display requirements can lead to changes in this module, increasing the risk of errors.

Another example describes the API interface of a modem:

Interface Modem{ public void dial(String pno); // pho means port number dial public void hangup(); // hangup hangup public void send(char c); // send Send public void recv(); // recv receives information}Copy the code

The word Modem is a bit strange, but Modem is a translation of Modem, which is probably better known by its transliteration as cat. Modem is a portmanteau of Modulator and Demodulator. Modulation is the digital signal into analog signal, demodulation is the analog signal into digital signal.

The API Interface of a Modem is the API Interface of a Modem. The Interface of a Modem is the API Interface of a Modem. The API Interface of a Modem is the API Interface of a Modem. Interface = Interface = Interface = Interface = Interface

A Modem’s API Interface is a Modem’s API Interface. In curly brackets is the API(Application Programing Interface). Then he added:

This interface does two kinds of closely related things, connection management (Dial,hangup) and data communication (SEND, RECV). Are they two kinds of responsibilities, or one?

The conclusion: On a case-by-case basis, it depends on whether changes in requirements cause these operations to change at the same time.

In the second part, my understanding is that there is no general criterion for determining this single responsibility, and it depends on the needs. What about “this interface does two kinds of things that are closely related”? My understanding of the interface is as follows:

But isn’t that about modules? Why are we talking about interfaces again? This interface does two kinds of things that are closely related.

I looked through Agile Software Development: Principles, Patterns, and Practices and realized that I may have overinterpreted it. It was a slip of the pen by the author of The Building Method: Modern Software Engineering. The example of Modem in Agile Software Development: Principles, Patterns, and Practices is an interface in Java.

So should connection management and data communication count as two responsibilities, or just one? To put it another way, in the case of eating, manipulating chopsticks and putting food in your mouth, from the point of view of eating, these two closely related tasks should be grouped into one module. This kind of logical division comes from our accurate understanding of eating, but what about other directions? There seems to be no absolute rule, but it is a case by case analysis to see whether changes in requirements always cause these operations to change at the same time.

When I write here, I suddenly think of microservices. At the beginning, the software was relatively simple with less code, simple business and less users, so most of the original software was integrated with the front and back ends. With the rapid development of hardware and the continuous popularization of the Internet, software is gradually getting closer to complexity, while the amount of code is also expanding. Software development is not a one-shot deal, unlike the house sold, it has little to do with the developer. After software development, maintenance should also be considered. In this respect, software development and construction are similar to urban construction. If a large number of people flood into urban construction, many people think that they can make money here, and the city rulers will start to expand the city to adapt to the current urban development. It is also like the development of society. It is impossible to compare the county magistrate in the feudal society in the past to the present. The county magistrate in the past collected many positions, which may be related to the population of the county in the past. This corresponds to the micro-service architecture. We disintegrate the applications originally concentrated on one service into several micro-services. Each service implements a single responsibility, and there is no duplication of external services, which also confirms David quoted at the beginning of this paper. Parnasse’s words:

The most useful technologies are no longer in the future, but have been around for years, and we’re just not using them properly.

I remember when I just learned Spring Boot. I watched teacher Yan Qun’s video at STATION B: SpringBoot video tutorial (introduction), at the beginning of the video talked about micro services, said that this is the current popular software architecture, I was quite novel, perhaps at that time did not develop a little project, the amount of project code is relatively small. The idea at the time was that microservices architecture was suitable for large projects, easy to scale up and maintain, but in recent years it seems that microservices are becoming the new normal. Is that still true? In my opinion, the microservice architecture is sinking. Is it important to expand and maintain the microservice architecture? It doesn’t seem to be entirely true. My personal view is that services can be reused, such as authentication services, if you develop them once, you don’t have to develop them again when you develop a new project, just reuse the old services.

This single responsibility can also be seen in the division of labor among Web software engineers, as we know that the hardware capabilities of many computers roughly double every two years. However, the process of software development has not been accelerated in this way, and the development cost has not decreased. The original Web engineer integrating front-end, back-end, operation and maintenance and DBA has been divided into four professions:

  • Front End engineer

  • Backend Engineer (also known as backend engineer)

  • operations

    DevOps is a portmanteau word that combines Developers and Operators in the current Web development world. The operation and maintenance that had been removed from the back end was returned to the back end.

  • DBA

Is it the idea of holding a hammer and seeing the world as nails? Seems to be, and seems not to be. Split and division of labor again human world can see everywhere, when you start a business, just small business at the beginning, you can not ask accounting registration company, just like the small restaurant in the countryside, you can be the boss can also be a chef, but also can be a waiter and accounting, cleaning. But you didn’t think your cooking is very good, delicious not expensive, the price affordable, your hotel soon attracted a lot of people, you slowly found that a professional life is more let you bear, there are too many people, in order not to let your parents involvement, you start hiring, cleaning and attendant responsibility assignment will you go out, you still don’t want to accounting, please. Do you think of your business is not so big, gradually found a cook you seem a little could not support the current users, you was tired to death every day, so you start wondering, recruit apprentice, cook, please make them responsible for cooking, you are responsible for into the dish, but seemed to recruit to wash dishes, to cook, wash dishes and cooking cook watch as heavy burden, cook has protested.

You want to expand your business, but the daily accounts are a bit of a headache. You don’t want to concentrate too much on the accounts. So you hire a cashier, and this story goes on and on, and you hire more people to do your work, but when you assign work, there’s as little overlap as possible between the two people, you don’t want one person to be the cook and the cashier, you want that person to be as professional as possible.

Another important software design Principle is the open-closed Principle (OCP).

Software entities should be extensible and immutable.

To be specific:

  • Allow Open for extension. When the requirements of the application change, we can extend the module to change its function
  • No Closed for modification is allowed. You do not have to change the behavior of a module when you extend it

So when should you use these principles? Agile Software Development: Principles, Patterns, and Practices also points out:

The axis of change has real meaning only if the change actually occurs. If there are no signs, it is unwise to apply SRP, or any other principle.

Following OCP is also expensive….. Obviously, we want to limit the use of OCP to changes that may occur. . Ultimately, we wait for change to happen.

My understanding is that these principles are to cope with the changes, the developer is forecasted according to the own experience think here will change, the need to design personnel have some predictive power from experience, experienced designers want to users and applications are very understanding, can in order to judge the possibility of change. He can then design to follow the OCP principles for the changes that are most likely to occur.

This is not easy to predict accurately, because it means making an educated guess at the changes that applications are likely to undergo over time. If the developer guesses correctly, they succeed. If they guess wrong, they will fail. And most of the time, they guess wrong.

How do we follow OCP? Let’s take a look at the following example to illustrate OCP:

This example also comes from agile software development: principles, patterns, and practices, which uses C++ to describe OCP, but I’ve changed it to Java. We can easily see that if we add another Shape, the drawAllShapes method in the Shape class will remain unchanged and draw the new Shape. Printing in a graph can be understood as the act of drawing the corresponding graph.

This design is OCP-compliant, and without changing the original code, we have completed the extension without causing cascading changes. This reminds me of the factory model. If you don’t know what the factory model is, please refer to my article: When talking about the factory method mode, we also abstract out the factory on the top floor, and the creation of concrete objects is undertaken by the specific factory, which is also in accordance with OCP to some extent. However, it is not easy to achieve the right abstraction, you need to know enough about the user and product, like POI WorkBookFactory, XLS is excel 03 and previous versions of the file format, XLSX is Excel 07 and later. The designers of the POI did not adopt the factory approach pattern, can we say that this design does not scale well enough?

If you add another Excel type, the WorkBookFactory will need to change. I don’t think that’s the case. I think the developers of THE POI think Excel won’t change that much, they won’t add another file format every year. At the same time, it also reduces the mental burden of developers to use POI. Excessive design leads to software complexity, increasing maintenance and use costs.

Is the Shape above perfectly in line with the open and close principle? Not quite, it seems, and we could have made a requirement that the drawAllShapes method would have to be modified. The change presented in Agile Software Development: Principles, Patterns & Practices requires that all circles must be drawn before squares, and in this case drawAllShapes seems unable not to be closed off from this change, Wouldn’t it be ok if you said you could put the circle before the square when passing in the List argument? So I’m going to make another requirement here, which is to draw the square and the circle together. Unless you are traveling through time, there will always be situations that you don’t anticipate, and no matter how “closed” the module is, there will always be changes that you can’t close off, and no model can handle all of them.

Since absolute closure cannot be achieved, the problem must be approached strategically. That is, the designer must make a choice about what kind of change the module he designs should have.

Developers must first guess which changes are most likely, and then construct abstractions to isolate those changes.

This reminds me of the design patterns, we think this is very useful, home of the interview is also very value, this to some extent led to the abuse of design patterns, the developers before did not have been familiar with specific business, began to expand, began using design patterns, it is easy to cause kinds of design patterns of the project, I remembered what the senior architect at my former company had said to me the other day when he saw me looking at design patterns and told me that for someone at my level, design patterns didn’t help me improve my code, and that he had used them a few times in all his years of development.

To summarize

Being familiar with the business allows you to see change, anticipate change, build abstractions to respond to change, and avoid a chain reaction of changes, because you don’t want to have to fix a Bug again after you’ve already developed it. My previous understanding of the open-close principle was that if the code in this part is already up and running smoothly, then do not change it as much as possible. So here I add the open-close principle, which is to predict changes based on experience, and then build abstractions to deal with the changes. It should be introduced with caution. It adds to the cost of reading and maintenance, but the rebuttal I often receive is that nothing will happen if I introduce it, so what.

Single responsibility before I understand is convenient and reuse, if A method to complete the A and B this two things, I suppose because some need to use A, B don’t need to use, so this way I will never, at the same time also make reading easier, I actually had the idea of can be covered in the change, I predict the future I will use A, My strategy is to make it as efficient as possible.

Planning and estimation

When you can measure what you say and put it in numbers, you know it. If you can’t measure it and put it in numbers, your knowledge is deficient and unsatisfactory. “– Lord Kelvin, British physicist

Is there will be a project to do the construction period, often allow developers to estimate time, this is a problem let me very headache, my project manager let me estimate of time, my brain is blank, I the idea was it to estimate without the need to work overtime, estimated that the project manager and are not satisfied, so I consult a predecessor of the company at the time, I put my worry about truthfully say, Senior said nothing, time is not enough to ask again. But I want to take stock, I want to have a measure of my development.

The technique of estimating seems easy, but it’s a very sophisticated one. When John Backus started his FORTRAN project, his supervisor would regularly ask him about completion dates. He always gave the same answer :” Six months.” But in reality, the project took nearly three years.

Before we start estimating, we need to clarify a few concepts: goals, estimates, and resolutions. We would not confuse these three words by themselves, but in practical application, we are easy to confuse these three words.

  • Goal: Indicates a desired state. For example, if you want to catch up with a girl, you should be aware that this is a goal that may or may not be achieved.

  • Estimate: How much effort and effort it would take to achieve something based on current knowledge and resources.

    In view of the current situation and resources I know, I remember that when I was in junior high school, I liked to read network novels. One of the novels that impressed me deeply was “Fighting through the Sky”, which was also a kind of estimation. I really wanted to learn this kind of estimation, for example, when we were in middle school, and one time middle school had a Thursday off,

    Next week I am full of expectations and hope that Thursday is also a holiday, MY estimate at that time is the weather, like a decent estimate of an 80% probability. But there was no holiday in the end.

  • Resolution: Ensure that predefined features and quality are completed by a certain time. If you make a resolution without a good estimate, then the probability is not achieved.

We see this in software projects, too, where delays are ubiquitous – why do we get it wrong? Because it’s hard? Why is software estimation so difficult? In fact, all estimates are hard, if you just make a wild guess and don’t figure out the assumptions behind the estimates. If you don’t believe me, let’s do some estimation exercises. Without using a search engine, you can estimate the following numbers (the order of magnitude is correct).

  • The length of China’s land border
  • Population density in Africa
  • The annual flow of the Yangtze River
  • The amount of money in circulation in Asia in 2013

How’s that？ How many orders of magnitude are your estimates off from reality? But if you list the assumptions that you’re basing your estimate on, doesn’t that make you more confident in your own judgment? “It’s not that we don’t know how to estimate,” says Paul Rook, an expert in software engineering. “What we really don’t know is that we list all the assumptions behind our estimates.” We usually estimate another dimension is to refer to the experience of predecessors. Over time, software engineers have developed a set of rules of thumb: the actual time spent depends on two factors — the estimated time spent on something, X, and the number of times he has done similar development, N.

Y = X ± X ➗N // Y is the actual time spent. The ± in the middle means plus or minus.

Such as graduate you have been assigned to a user management module of the task, you estimate need three days, but you have never done the user management module, so N is 0, the high school math tells us that 0 can’t be divisor, but tell us university mathematics can limit case, so you spend time is 3 + infinity? That is to say, the project can’t be completed at all in the given time, or 3-infinity? Instead of getting the job done, a lot of bugs were written that took the team more time to deal with and dragged the project down.

Note that this is an empirical formula, so it is quite normal to have an error with the actual time spent. This requires you to analyze the reasons after completing the requirements in order to reduce the error. If you keep doing the same project, the estimate will be more accurate because you are more proficient. But no one wants to do the same thing all the time. It gets boring.

Write in the last

At the end of my writing, I suddenly felt that this article didn’t quite look like a book note for “How to Build: Modern Software Engineering”. When writing software design principles, I referred to agile Software Development: Principles, Patterns and Practices, which only spend two pages in “The Method of Construction – Modern Software Engineering”, but the main content is still from it, but also mixed with some of their own feelings, I hope it will be helpful to you. The cover was taken by someone else while I was on vacation in Hainan. It felt very beautiful.

The resources

  • The method of construction: Modern Software Engineering. Third edition by Zou Xin

  • The function of the modem is to implement

  • Why do big factories have to use DevOps?

  • 【 原 文】 Talk about the Open/Closed Principle.

  • Agile Software Development: Principles, Patterns, and Practices. By Robert C. Martin