"No Silver Bullet" and Lego Programming | December 15, 2006
by Jeb Boniakowski
Joel Spolsky wrote an article recently that's partly about the problems with technology journalism and partly about how No Silver Bullet implies that "Lego programming" will never make software development easier.
Software developers seem to have something of an immunoresponse to some of these ideas, one that's oddly not unlike the response Joel describes "real" C++ programmers having to VB. We saw this in the comments on a CNet article about Coghead.
I think the fundamental misunderstanding here is that those of us in the Lego programming community don't intend to replace VB for building the next Quicken, just like the designers of VB didn't intend to replace C for writing video drivers. Rather than comparing Lego programming tools to C#, we should be comparing them to Excel, Access, Filemaker, and Lotus Notes.
The Real Slashdot Effect
It's also odd to specifically choose No Silver Bullet to make this argument, and the whole thing points to a general pattern in the builder->tech press->elite members of tech community->normal people idea-transfer cycle, which was nicely summed up by one of my coworkers, Sijin, in an email I hope he won't mind if I quote from verbatim:
afaict, most instances of decrying a solution b/c the problem itself has no silver bullet follow a curve something like:
- Someone makes a meaningful breakthrough on a difficult problem.
- Whether due to ignorance or incentive structure (notable stories are more valuable than unnotable stories), press coverage of the solution hails a changing of the guard and a new and drastically improved world as a result of said breakthrough.
- Experts in the field react to the press – as distinct from the breakthrough – and say all this hullabaloo is ridiculous since no single improvement, no matter how substantial, can sink the problem.
- The enthusiasts reaction to the expert response is that the entire thing’s a wash.
...when all the while, the original breakthrough does in fact make a substantial improvement for all involved.
This is the same reason 3rd year CS students used to think VB was useless.
50% Thought-stuff, 50% Expletive-stuff
Brooks breaks down software development difficulties as follows: "Following Aristotle, I divide them into essence, the difficulties inherent in the nature of software, and accidents, those difficulties that today attend its production but are not inherent." (By the by, how can you not love a guy writing a software development essay who includes "Following Aristotle" not as a joke? This is just one example of how Brooks rules.)
Joel latches onto this section:
Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any—no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware.... I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.... If this is true, building software will always be hard. There is inherently no silver bullet.
This seems to be a concept that's close to Joel's heart. There's a number of articles Joel's written about how "executable specs" will never work because by the time you spec out what should happen when a user deletes a file while another user has the "Open" dialog box open and picks that file, you're at code-level detail, the kind of stuff that would never come up during spec-writing. Unfortunately, I'm not finding these articles right now. Fortunately, Joel has one of the better-designed archive pages on the Internet, which I'm sure you'll enjoy if you've made it this far into my screed.
We agree that the specification, design, and testing of the conceptual construct are the major complexities of developing most apps at this point. However, we think even if there are no "silver bullets", there are certainly a lot of extremely useful things to be done. I also might ask Joel how he squares his opinions on automatic memory management and flexible type systems with his belief in the non-existence of silver bullets. First of all, there's a big difference in edge-case coverage for an app that's going to be used by one person: every programmer knows this. When you write a shell script to rename all your digital camera photos, you do not check to make sure that it works on Hebrew Windows NT 4.0. You make it work for you and the people immediately around you with the exact same problem as you, who can deal with some additional limitations. This alone reduces app complexity by an order of magnitude, provided you can expand the universe of "software developers" such that its economic to build applications for such small audiences.
Even more important is the issue of specification: figuring out exactly what it is the user needs the app to do. Usually, the user doesn't even know until they've used version 1.0. I think this is why so many of the loudest voices in the Agile camp are ex-enterprise developers. This is enterprise developers' daily life: work on an app that solves a domain problem you don't really deeply grok like "show me the risk in my esoteric financial instrument portfolio", give it to the user, find out the user wants everything changed, even though you built it to spec. This is the source of the Agile mantra: "get the app in front of the user as quickly as possible." It's a different problem domain. When you are building C3, you don't worry about the Marimba Phenomenon.
Brooks brings up a lot of these points in NSB "Therefore, one of the most promising of the current technological efforts, and one that attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements." When you hit the limits of your Lego programming, the user can kick the performance bottleneck up to the real engineers, people who crack jokes based on the NUXI problem over bottles of Bawls.
Brooks goes on:
A prototype software system is one that simulates the important interfaces and performs the main functions of the intended system, while not necessarily being bound by the same hardware speed, size, or cost constraints. Prototypes typically perform the mainline tasks of the application, but make no attempt to handle the exceptional tasks, respond correctly to invalid inputs, or abort cleanly. The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability.
This is related to another point that we think big progress can be made in: pick reasonable defaults. To go back to the "user opening file that no longer exists" issue, let the user reuse your "file open" primitive. Recover gracefully in a reasonable way from this failure. It means the user won't be able to change the way that file dialog works, or supply a custom message, or do something fancier when that edge-case happens, but it also means the app won't crash and the user doesn't have to think about it. Users can manually special-case exception inputs, they built the system so they know how to do it, and they can extend their app to catch them in the future if so desired. Reasonable defaults and lots of framework, admittedly at the expense of overall flexibility (no one's going to be building Doom in Proto) let users convert these prototypes into useful applications.
Spreadsheets: Duplo Programming
One of my favourite "No Silver Bullet" quotes, though, is:
There are dramatic exceptions to my argument that the generalization of software packages has changed little over the years: electronic spreadsheets and simple database systems. These powerful tools, so obvious in retrospect and yet so late in appearing, lend themselves to myriad uses, some quite unorthodox. Articles and even books now abound on how to tackle unexpected tasks with the spreadsheet. Large numbers of applications that would formerly have been written as custom programs in Cobol or Report Program Generator are now routinely done with these tools.
Exactly. The spreadsheet is the original Lego programming environment. It turns out there is a lot of improvement that can be made in that area. That's what we're trying to do here, not replace C++. (Actually, if there's something we could do to rid the world of that abomination I'd get behind it. Telethon anyone?)
I could seriously go on about this for about ten times longer than I have, but the point here is that silver bullet or no, non-engineer users have already demonstrated their ability and willingness to build custom apps using spreadsheets, desktop databases, and Lotus Notes. By giving them better and more powerful tools, users can get the apps they want and in-house developers can spend less time fielding "can you move this button over here?" requests and more time building interesting and powerful systems. Everyone wins.
