Dijkstra said in the 70s that the irreversible damage is done once we have named this subject “Computer Science”.
“…the topic became —primarily in the USA— prematurely known as “computer science” —which,actually is like referring to surgery as “knife science”— and it was firmly implanted in people’s minds that computing science is about machines and their peripheral equipment, which is not true””–from Wikipedia.
Now we see the damage.
Those of us who work in the software industry know that there is a huge divide between tech and product people.
There is a general distrust of engineers:
1. engineers cannot manage, not even manage themselves. So they need to be managed
2. engineers don’t care about products and don’t know about design
Both of these are not true. My experiences told me otherwise. Engineers dislike management, mostly because management doesn’t understand software and so the management is a lot of obstacles to software engineers. Since software engineers don’t see the hope of changing the situation, they would rather stay in their corner and be happy to just focus on engineering. I know this is true for a lot of software engineers.
As for caring about product, software engineers care about product and design greatly if you give them the chance. When I was working as CTO for a company, I had a design session that goes along with weekly meetings. The software team members take turns to share with others what they see as a good design or a bad design in their daily lives, and why it is good or bad. So engineers discussed toilet, road/subway signs, light switches, power sockets, organization structure, and so on. I take the opportunity to introduce to them various related design topics when we are discussing design of one thing. And engineers get very excited about design of various things, including organization management, social policies, and so on. Who said they don’t care about product? Who said they don’t know about design?
The engineers in the above example is from a conventional company that is going online. They have shown disinterest in company product and management, and are believed by the company management as cannot be trusted on responsibilities (sounds familiar?). They didn’t care because the management didn’t want them to care and didn’t give them the time to care. For a change, I let engineers take Friday afternoon off to just focus on product. I don’t assign any engineering tasks to them for that half day. And they just use the time to play with company product. And with inner source environment I built up, engineers can initiate projects that they deem important for company product. And we have important projects sprung up because of that. For example, an IM product/software for our eCommerce platform.
If you give them the chance, they will care, because that is what software programming is about.
These two assumptions are not true probably for all engineers. But particularly, it is not true for software engineers at all because of the uniqueness of software.
However, for the general public, people assume the above two misconceptions about software engineers, due to the misnaming of this subject—Computer Science, and more in depth due to the fact that software is complex and invisible. (You can only see it if you do hands-on practices. Very much like society or sociology is invisible, and you have to “see” it with your hands-on practices.)
“We have everything ready, we just need a programmer!” is the typical expression that reflects the common mass’ perception of software engineers.
When there is a divide, usually it is because it is difficult to possess both qualities. Since we called this subject “Computer Science”, it is believed to be a purely engineering major. So then there should be people who study liberal arts majors to manage these software engineers, because typically we believe engineers are narrow minded, not able to communicate well, and don’t care about management and product. And we know our schools taught these two groups of people like they are totally different, and there are generally no much coverage of liberal arts for engineering students.
Thus we have product people and engineering people in every company. And very often they fight each other. Surely a lot of decisions have to be made on the whole since product is one whole piece and is not separated by product vs engineering. So very often we see the boss or one of the founders sit on top to make the important decisions, even though s/he is not capable of making those decisions. It is assumed that it is easy to understand what is in software. And there is no understanding that great skills and years of experiences are needed to plan product and software together and it is very strategical for a company whether it can plan the software/product well.
“Dijkstra was the first to make the claim that programming is so inherently complex that, in order to manage it successfully, programmers need to harness every trick and abstraction possible. ”–from Wikipedia.
Complexity of software demands ability in both liberal arts and engineering. Society is complex and invisible, thus you need to do a lot of hands-on social practice and do very extensive reading to help you “see” things and understand human society. Similarly, as software is essentially a digitization and innovation of human society, it is also complex and invisible. You needs hands-on practices, e.g. coding to “see” things and understand it. Since it is about digitization and innovation of human society, you also needs a very strong liberal arts background. Not the kind of liberal arts education you get from college, but more street-smart liberal arts capacities achieved only by a lot of social practice and a lot of extensive reading. For a small example, knowing of the human history helps you innovate better.
So maybe now it is easy to understand why such a divide between product people and engineering people. We can say that is because product people are not really product people, they don’t possess the true liberal arts capacities, and cannot think logically. They are just chatty. And our engineers are not true engineers because they focus so narrowly only on the engineering aspect of the software programming, and cannot grasp the vast realities and possibilities outside of engineering domain. Or we can say we just need people who educated themselves in liberal arts and have a lot of hands-on experiences with coding. Since software programming is so big and encompassing so many things, it is challenging for an individual to learn all these things and be good at all of them. But it is reasonable to expect a general good grasp of both and be a little leaned towards one side or the other from time to time, with the ultimate goal of achieving the level of greatness in both regards.
And that is possible. We have seen great examples of people who have achieved that greatness, and we believe it is a path that everyone can try.
I believe Jeff Bezos, Larry Page, Steve Jobs, Bill Gates, Mark Zuckerberg, Linus Torvalds, Guido Van Rossum (for Chinese ones: Huateng Ma, Xiaolong Zhang, Lei Ding, Bo Yang from Douban…) are these good examples. And we also see many other smart creatives as touted by Eric Schmidt’s book “How google works”. I believe all great software companies understand this and know how to build up organization accordingly to tap into potentials of software engineers, such as google, amazon. And those who don’t, disappear after a while even if they can have a short period of success.
We have to bridge the divide. Without bridging the divide, there is no real solution for the industry. We have to point out a path and show the examples.
Without detailed elaboration, just let me briefly outline my understanding of this path:
- emphasize caring of product, emphasize responsibility for full life cycle of the software like amazon has practiced (Douban as an example as well). Give developers dedicated time to care about company products. Give them rights to initiate products on their own (like Douban has practiced, and inner source environment can legitimize, empower and reward such behaviors.);
- emphasize on programming as the core. Like the core curricular in college, programming should be the core skills you have to learn no matter you are developers, QAs, devops, product managers, and so on. In the words of facebook director of engineers, if you are doing any software related job, your best way to prepare yourself for that job is to learn how to program. Build up an inner source environment with rich projects of various scales and difficult levels that people can pick best projects that suit their current capabilities. People including non-engineers can be free to contribute to any inner source projects and learn various programming skills. Remove the artificial barrier that blocks communication between developers, QAs, devops and product managers;
- emphasize on design skills training. Such as the design sessions that I practiced in my previous companies. Such design skills are inherently connected to architecture and management skills. In a sense, it is a more advanced level of coding;
- give people ownership in those independent projects of various scales. That is how people learn of programming, design and management. They need to feel the whole and develop the sense of it. The wholeness is essential to programming and here I use the word programming as something that is very broad.
So we do have a path that can connect liberal arts with science/engineering and making them mutually benefiting each other. You don’t have to struggle between whether you should go product direction or engineering direction. You just try to be good at both, and make the two Ying and Yang of one whole body. They are parts of the whole thing of digitizing the world and making the world a better place with great and kind innovations, thus truly making software programming the greatest ever invention of human history, an invention that empowers us to break the long time barriers to equality and happiness of mankind.
One great person who has been trying hard to bridge liberal arts and science is Christopher Alexander, whose design pattern theories in the 60s, 70s have greatly influenced software community, and directly brought up the design pattern, OOP, extreme programming, and agile programming movements. However, during a speech of Christopher Alexander, when asked to comment on his influence on software community, he said that in his observation, software community has only scratched the surface of his theory, quote “Software Programming’s use of patterns have so far just been a neat format that is a good way of exchanging ideas about programming, but lack in the two other dimensions: MORAL CAPACITY in producing a living structure and the GENERATIVITY OF THE THING and that is capability in producing a coherent whole.” (http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=795104) His latest theoretic framework, as summarized in Nature of Order, has used concepts like life centers and degree of life to push his works to a whole new level. However, software community has barely touched on these and probably have no idea how to tap into it.
So by bridging the gap between product and engineering, and realizing the true nature of software programming, I hope not only that we can resolve the great divide in our software industry and help the industry grow more healthy (as we see software nowadays is really expanding to all corners of human society, literally “eating the world” according to Mark Anderson), we can also to bring up a new (real) kind of software engineering that seamlessly bridge liberal arts and science/engineering, tap into the great potential of Alexander’s great theoretic framework that bridge the gap between subjectivity and objectivity, and make complete the modern science.
