Some truth about software
Truth About Learning
From Peter Norvig:
Researchers (Hayes, Bloom) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene, appearing on the Ed Sullivan show in 1964. But they had been playing since 1957,and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967. Samuel Johnson thought it took longer than ten years: “Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price.” And Chaucer complained “the life so short, the craft so long to learn.”
Truth About Reuse
Reuse is largely a failure. The primary reason is that making things reusable requires extra work, and there is no real incentive to do it. Moreover, people seem to think that reuse comes for free with OO languages, but this is a mistake from reasoning about implementation inheritance.
–Patterns of Software, Richard P. Gabriel
Truth About Reuse
Every manager learns that reuse requires a process of reuse or at least a policy. First, you need to have a central repository of code. It doesn’t help if developers have to go around to other developers to locate code you might be able to use. Some organizations are small enough that the developers can have group meetings to discuss needs and supplies of code.
Second, there has to be a means of locating the right piece of code, which usually requires a good classification scheme. It does no good to have the right piece of code if no one can find it. Classification in the world of books, reports, magazines, and the like is a profession, called cataloging. Librarians help people find the book. But few software organizations can afford a software cataloger, let alone a librarian to help find the software for its developers. This is because when a development manager has the choice of hiring another developer or a software librarian, the manager will always hire the developer. . . .
–Patterns of Software, Richard P. Gabriel
Truth About Reuse
Third, there must be good documentation of what each piece of code in the repository does. This includes not only the interface and its purpose but also enough about the innards of the code—its performance and resource use—to enable a developer to use it wisely. A developer must know these other things, for example, in order to meet performance goals.
In many cases such documentation is just the code itself, but this information could be better provided by ordinary documentation; but again, a development manager would prefer to hire a developer rather than a documentation person. For a lot of pieces of code it is just plain simpler to write it yourself than to go through the process of finding and understanding reusable code. Therefore, what development managers have discovered is that the process-oriented world of reuse has too many barriers for effective use.
–Patterns of Software, Richard P. Gabriel
Truth About Reuse
However, the form of reuse in object-oriented languages hardly satisfies the broad goals of software development. What I want to suggest is a better word than reuse and maybe a better concept for the reuse-like property of object-oriented languages.
The word (and concept) is compression. Compression is the characteristic of apiece of text that the meaning of any part of it is “larger” than that piece has by itself. This is accomplished by the context being rich and each part of the text drawing on that context—each word draws part of its meaning from its surroundings. A familiar example outside programming is poetry whose heavily layered meanings can seem dense because of the multiple images it generates and the way each new image or phrase draws from several of the others. Poetry uses compressed language.
–Patterns of Software, Richard P. Gabriel
Truth About Reuse
Reuse is the holy grail of software engineering, one that is so entrenched in our belief system no one dares to question its virtue. The quest for reusable components is one of the foundations of object-oriented programming and all of the tools and languages that OOP has spawned.
Yet, my observations suggest that at least in the embedded space reuse has been a dismal failure.
–Jack Ganssle, Embedded.com
Truth About Reuse
Martin Griss and others have observed that a module isn’t really reusable till it’s been reused three times. No matter how good our intentions, the first time we try to reuse something we discover a facet of the new problem the old module just can’t manage.
So we tune it. This happens a couple of times till the thing is generally reusable. That’s not because we’re stupid; it’s simply because domain analysis is hard. No one is smart enough to understand how a function might get used in other apps. It’s expensive to do a forward-looking design of a function or module. You’ll always save money in the short term solving today’s very specific problem, ignoring the anticipated demands of future projects. If you elect to pursue a careful program of reuse your projects will initially come in late and over-budget.
–Jack Ganssle, Embedded.com
Truth About Reuse
Failures were due to not introducing reuse processes, not modifying non-reuse processes and not considering human factors. The root cause was the lack of commitment by top management, or nonawareness of the importance of these factors, often coupled with the belief that using the object-oriented approach or setting up a repository would automatically lead to success in reuse.
–Success and Failure Factors in Software Reuse, Maurizio Morisio, Michel Ezran, Colin Tully
Truth About Design
Agile methods are finally trying to tell the truth about design: That when designing a new thing, you need to be building it too. Here is why:
Agile methods seem to all be solving a pair of simultaneous problems: creating in an artistic mode while at the same time doing careful engineering. Developing software systems is a creative activity requiring the techniques of science, engineering, and art; and software, unlike art, is also required to perform via execution on (networked) computer hardware.
Deep Trouble
Computer Science is in deep trouble. Structured design is a failure. Systems, as currently engineered, are brittle and fragile. They cannot be easily adapted to new situations. Small changes in requirements entail large changes in the structure and configuration. Small errors in the programs that prescribe the behavior of the system can lead to large errors in the desired behavior. Indeed, current computational systems are unreasonably dependent on the correctness of the implementation, and they cannot be easily modified to account for errors in the design, errors in the specifications, or the inevitable evolution of the requirements for which the design was commissioned. ( Just imagine what happens if you cut a random wire in your computer!) This problem is structural. This is not a complexity problem. It will not be solved by some form of modularity. We need new ideas. We need a new set of engineering principles that can be applied to effectively build flexible, robust, evolvable, and efficient systems.
–Gerald Jay Sussman, MIT