So-called Software engineering

Many programmers include me, the title is "software Engineer" (software engineer), but I do not like the name. I like to call myself "programmer" (programmer) or "computer scientist" (computer scientist). What is this for? This needs to be discussed from the meaning of "software Engineering" (software engineering) in reality.

Someone has summed up the nature of the field of software engineering as follows: "How do you cannot?" "(If you don't program, then how do you program?) I think this sentence is very good, because I found that the whole field of software engineering, basically is bragging about selling "diet pills." Much of the puzzling folly of the software industry has been invented by so-called "software engineering experts". There has always been a condom called "methodology" or "principle", such as extreme programming,design Patterns,agile,pair programming,test Driven Development (TDD), DRY principle, ... They tout these so-called methodologies to various software companies, advocating for their benefits, saying that using these methods can create high-quality, low-cost software with some mediocre "software engineers". This is the same as the weight-loss drug ads: No exercise, no diet, one weeks thin 20 pounds. You don't think about it at the beginning, and you feel how these superficial statements can affect you. As a result, these so-called "methodologies" and "principles" have become dogmas throughout the industry, creating the same ethos as the Cultural Revolution. Those who violate these doctrines must be regarded as the same as the Novice's contempt, as a primary school education, as the "counter-revolutionary" interrogates. Even if your skills are better than those of the dogmatic advocates, you don't know how many times.

One way to break the illusion created by these software engineering experts is to look in the field to see what these so-called experts have done with these methodologies. You will be surprised to find that these so-called "experts" iffy its xuan of the term, almost all never know what is out of the corner of the civil branch, no one has made any technical content, they simply do not have the capacity to guide others in the way of programming. It's so easy for these people to make a handful of things (like JUnit) that every novice programmer should be able to do. But in the world there is such a cost-effective occupation, although you can not write good code, your understanding of the principle of computing is very superficial, but by some means, to evaluate the other people's "Code quality" power, occupy the management position of the software company. Over time, others think you are the leading authority. Have you looked closely at the four people (GoF) who proposed Java Design pattern, and have you ever done anything serious? No. Has the author of "DRY Principle" made any good things? No. And look at Agile,pair PROGRAMMING,TDD ... Of the proposed person? It's all a bunch of idiots. They actually do not understand a lot of programming things, writing articles and books is extremely superficial, smattering.

The so-called "software Engineering" is not like civil engineering, mechanical engineering, electrical engineering, is based on the actual, scientific basis. With these "hard works" is not the same, the software is not deadly, nor with the chip company, a bug immediately caused by billions of losses, ruin. So the study of software engineering, seems particularly easy to exploit, after failure easy to find excuses and scapegoats. If you say my method is not good, what evidence do you have? Accreditations, how much time did I waste? Is your specific execution exactly what I said? You must have some details that you did not do as I said, so you will fail. In short, if you use my method does not work, it is your own problem!

Think of these excuses I think of a joke: Two couples sleep found a flea in bed, the body was bitten a lot of big bags. To buy a "kill rate 100%" of the flea medicine, sprinkled a lot in bed. The next morning, I woke up and got bitten by a lot of new bags. The wife blamed her husband and said he was scattered without reading the instructions. As a result, the husband opened the instructions and read the following:

How to use this flea medicine:

1. Catch the Flea.
2. Break the Flea's mouth
3. Put the medicine in the flea's mouth.
4. Close the flea's mouth.

I've found that many of the excuses behind the so-called methodological failures of software engineering are much like the description of the flea medicine:)

People want to save money, hiring high-quality programmers is not easy, so many companies are still hooked. They asked these "Software engineering experts" to come to the company and implement a variety of software methodologies, but found that they failed at the end. What is this for? Because of the sophisticated methodology, can not replace the real, the essence of computer science education. Until today there are many companies that are pushing the so-called agile, stand-up meeting, scrum and other formalism, think that these house-like practices can improve the quality and efficiency of development. Many developers also take some software engineering tools seriously, like tossing git,maven and other tools for some remote "new features". They care so much about versioning, testing, and so on, that they can develop high-quality, reliable code by mastering these skills. But you finally find that no matter how efficiently you use these tools, they can only play a secondary, secondary role. Programming tools are never the program itself, and the mastery of programming tools is never a substitute for real understanding of programs and computations. Too much emphasis on the use of these tools, is putting the cart before the horse, so that the project on the road to failure.

Programming is really an art, it fully conforms to the various characteristics of the arts, the programming community is also full of the unique characteristics of the art world. Some beginner artists (like me 10 ago) are always picky about the tools they have, rather than using the latest and most dazzling tools, using their most remote and difficult "features" to feel they can make good work. Many people can't take good pictures, they blame the camera is bad. Bought tens of thousands of dollars of bulky high-end cameras, photos are not as good as others to use mobile phone photos. These people don't understand that good photographers and bad photographers differ in the eyes, not the camera. A real artist can create great works with any tool on hand. Some can even use some rubbish, poor tools, to make outstanding, flavor of art. Because art exists in people's hearts, not in the tools they use.

More Good Articles

So-called Software engineering