No silver bullet notes

No silver bullet 1987¶

Summary¶

“No silver bullet” talks about why software is difficult, past discoveries that improved productivity, what could improve it, and what people think would but likely won’t.
A silver bullet refers to magic solution for all your problems.

read it No_Silver_Bullet_Essence_and_Accidents_of_Software.pdf
discuss https://wiki.c2.com/?NoSilverBullet

Notes¶

software is difficult¶

• complexity leads to difficult communication, bugs, etc. this also is a big topic in A Philosophy of Software Design
• conform: all software is different, different interfaces etc.
• changeable: easy to change unlike real life buildings, cars, … so it’s more tempting to introduce changes mid production.
• invisible. you can’t see software, you can’t easily draw a representation. 2 minds struggle to communicate. ¹

past breakthroughs¶

• high level languages make devs more productive. Removing some complexity.
• time sharing, not really understanding this. Seems related to submitting jobs in a queue
• Unified programming environments make it easier to use apps together. And create reusable tools

I’d add sharing code and libraries to this, e.g. open source, package repos, ..

hopes for future breakthroughs¶

• Ada and other high-level language advances: a specific language, seems outdated. Described as likely not a breakthrough
• Object-oriented programming. removes some complexity but not enough. ²
• Artificial intelligence Author did not expect AI to have a big impact ^{3 4}
  but was wrong, 35 year later AI is taking over
• Expert systems: A rule based manual written “AI” system. ³⁵
  The most powerful contribution by expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers.
  This basicly describes chat GPT.
• Automatic programming: dated, chatGPT now can help here. ⁵
• Graphical programming ⁶⁷
  • argues flow chart is a bad representation ⁸, devs draw flowcharts after, not before
  • screens are to small. dated, now you can zoom easily e.g. on Miro
  • difficult to visualize
    These days node-based programming has it’s place, e.g. Unreal’s material editor & blueprints. It does often result in messy spaghetti though.
• Program verification: testing & bug fixing. Unit testing doesn’t save much labor, since you need to write & maintain the tests.
• Environments and tools expect marginal improvements.
• Workstations Better GPU, CPU Ram won’t reduce think-time for a dev. Slightly dated since GPU advancements lead to AI, which significantly sped up dev process. Increase of hardware also enabled cloud.

so what can we improve¶

all productivity improvements are limited by (reminds me of this xkcd)
\(\(Time of task=∑(Frequency×Time)\)\)
If most time is spend on the concept, instead of the technicalities of software, then focusing on improving technicalities wont improve productivity much.

Buy versus build. The most radical possible solution for constructing software is not to
construct it at all. Proposes marketplace for modules ⁹

• saves money
• but can it be applied to my problem?
  • people used to buy custom programs, now they buy of the shelves. Because a computer used to be 2mil, an extra 250k for software was ok. Now a computer is 50k, so custom software is relatively much to expensive.
• spreadsheets have solved many problems, removing need for custom apps.
• many computer users now solve problems without any coding knowledge

Requirements refinement and rapid prototyping
The hardest single part of building a software system is deciding precisely what to build…
No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

• client doesn’t know what they want exactly. Plan for iterations
• it’s impossible to set final specs before trying a version of the product
• rapid prototyping tools promise big productivity gains
• prototype the important interfaces, and perform the main functions. without worrying about performance or hardware limits. main purpose is so client can test it.
• present day development (1987) relies on final specs before starting development, which is flawed. Instead you should build (not write) incrementally.
• building is now dated, living things grow instead. ¹⁰
  • first make it run
  • bit by bit flesh it out, with calls to empty stubs.
  • improved performance & understanding with students#
  • ⚠️ One always has, at every stage in the process, a working system ¹¹

Great designers

• To improve the software, you need good people
• Good design practices can be taught, and can change poor design in to good designs

• But won’t turn good designs into great ones. Great designs come from great designers.
  Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. ¹² The differences between the great and the average approach an order of magnitude.

• So the most important single effort we can mount is to develop ways to grow great designer

  1. reward amazing devs with huge salary, perks, status. (FAANG does this now)
     • Identify top designers early, the best are often not the most experienced.
     • Assign a career mentor responsible for the development of the prospect, and keep a career file.
     • Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo-design and technical leadership assignments.
     • Provide opportunities for growing designers to interact with and stimulate each other.

REFERENCES¶

Backlinks¶

• books
  • summaries:
    mirror - thomas j frank notes - hyperfocus
    The DevOps Handbook
    Range - Why Generalists Triumph in a Specialized World
    no silver bullet notes
    Art of giving feedback
    A Philosophy of Software Design
    Algorithms to Live By