An interview with Sun’s Victoria Livschitz:
What about the notion of complexity as the primary reason for software bugs? Do you have any concrete ideas on how to reduce complexity?
Well, I see two principal weapons. One is the intuitiveness of the programming experience from the developer’s point of view. Another is the ability to decompose the whole into smaller units and aggregate individual units into a whole. Let me start with the programming experience first.
Things appear simple to us when we can operate intuitively, at the level of consciousness well below fully focused, concentrated, strenuous thinking. Thus, the opposite of complexity — and the best weapon against it — is intuitiveness. Software engineering should flow from the intuitiveness of the programming experience. A programmer who works with complex programs comfortably does not see them as complex, thanks to the way our perception and cognition work. A forest is a complex ecosystem, but for the average hiker the woods do not appear complex.
How well do you think modern programming languages, particularly the Java language, have been able to help developers hide complexity?
Unfortunately, I believe modern computer science and software engineering have failed to make significant advances there. The syntax of all mainstream programming languages is rather esoteric. Mathematicians, who feel comfortable with purely abstract syntax, spend years of intense study mastering certain skills. But unlike mathematicians, programmers are taught to think not in terms of absolute proof, but in terms of working metaphors. To understand how a system works, a programmer doesn’t build a system of mathematical equations, but comes up with real-life metaphor correctness which she or he can “feel” as a human being. Programmers are “average” folks; they have to be, since programming is a profession of millions of people, many without college degrees. Esoteric software doesn’t scale to millions, not in people, and not in lines of code.
I certainly can’t gainsay striving to develop more intuitive programming languages and development methodologies. But the idea that making programming more accessible to average folks would prove an effective means of reducing bugs makes as much sense to me as getting better bridges through making bridge design more accessible to average folks.
I’m not at all sure that software development not scaling to millions of people isn’t simply a constraint we have to live with. And that there might be more to gain by making programmers more productive than by enabling a larger number of programmers. Even if this means countenancing code that may be unreadable to an average programmer.