No Silver Bullets
Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.
https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html
Fred Brooks, in his essay No Silver Bullet identified a three-part plan for finding great software designers:
- Systematically identify top designers as early as possible.
- Assign a career mentor to be responsible for the development of the prospect and carefully keep a career file.
- Provide opportunities for growing designers to interact and stimulate each other.
This assumes that some people already have the qualities necessary for being a great designer; the job is to properly coax them along.
(source - Quora)
Joshua Gross - Associate Professor of Computer Science at CSUMB
Originally Answered: Hasn’t Deno broken the No Silver Bullet software engineering prediction by Fred Brooks?
The rest of the title of the paper is informative. The full title is “No Silver Bullet — Essence and Accident in Software Engineering”.
Brooks made a pretty conclusive argument that there are two kind of challenges that software development faces. The first he calls “accident” but we might call “incident”, and they are the problems that emerge from the limitations inherent in all of our tools. We can eliminate any of these, but not all of them; new ones emerge as expectations increase.
The second are the problems inherent in the very activity we’re talking about. The issues he labels as “essential” (essential as in “an inherent and unavoidable part”, not as in “needed”).
These problems aren’t about tools. They aren’t even about processes or teams. The essential problems of software engineering have to do with the malleability of software, and thus the expectation that we can and should alter it quickly.
Before anyone builds a bridge, extensive planning and research is completed. Options are considered. Sites are surveyed. Traffic is measured. Math is mathed. Only after all of the preparation is done does the bridge start to go up.
But software, now software is easy. Have an idea? Start to build it. Unlike the bridge, it’s all but guaranteed to be a novel system, because if it weren’t, someone would just use existing software.
When bridges are novel, the planning and research activities are larger and longer, and even so, there are problems. The Big Dig, which rerouted I-93 under Boston, was a nightmarishly complex project plagued by cost overruns, and it even ended in one death.
Basically, software is so easy to build that the world demands we just plow ahead and start, and needs and expectations change continuously. The issues with expectations, communication, and specification are inherent.
When those problems can eliminated, software is easy to develop correctly. The problem is that those problems are essential, are part of the essence of, the vast majority of software development projects. The exceptions are things like class assignments.
ChatGPT can provide correct and even good implementations of homework projects used in CS courses, but industry folks are kinda meh on it. Why? Because college professors specify our assignments carefully and in detail. That’s not what real software development is like. And that’s essence, and can’t be done away with.