Smart Software

Conversational Interfaces Redux

In the past, I have talked about conversational interfaces with posts like the “Turing Test and the Loebner Prize Competition.” My interests are not purely theoretical, as I have actively explored integrating natural language deeply into applications in such ways as interpreting all text inside documents and code files and presenting a conversation stream.

The company I founded, SoftPerson, LLC, develops “smart software,” which are desktop applications that utilize mostly symbolic artificial intelligence including natural language processing. The overarching design criteria for my software is the capture of human thought process—human-like reasoning—into the codebase, so that software ultimately acts as an intelligent agent—a “soft person” or a virtual replacement for a human. In a sense, the applications are similar to Siri, which describes itself as a virtual assistant.

(The desktop market may seem mature, but there are many more undiscovered document types and, even in existing categories, there are additional ways of differentiations. Software applications are a high margin business. Despite Microsoft having a monopoly on some desktop application, niche versions of existing types of applications make considerable sums for their owners, and many successful companies are based on a single product: WhiteSmoke, FinalDraft, Moos ProjectViewer, SmartDraw, Quantrix, and Ventuz.)

In a sense, computers have historically been conversational, with a command line console being a form of conversation in which the user communicates to the computer in the computer’s own language with its limited grammar. The trend is moving towards the other end, where the computer understands more and more the language of the user.

The business plan I wrote for SoftPerson in 2002 featured a natural language writing product that incorporated a conversational interface in one of three different writing modes. Rather than feeling forced, the conversation interface was more natural than the one it would replace. The software would become one’s own personal ghostwriter. The plan was a finalist in two national business plan competitions and won prize money in the 2002 New Venture Championship competition held in Portland, Oregon. I have been working on this product for some amount of time. It includes a natural language parser that is an improvement on the Link parser from Carnegie Mellon University; however, the parser may be switched to the Stanford parser, which is more accurate, for a licensing fee.

I won’t talk much about the aforementioned product for intellectual property reasons, but I did look into the possibility of creating a graphics program by simply describing the desired image through words or sketching or other forms of input just as much as one would dictate to a human artist. In effect, the computer becomes one’s own personal artist.

Wouldn’t it be great if a computer can dynamically produce any image a person would so desired? How much more versatile could software be if it could render arbitrary scenes depending on the context as part of their operation instead of canned photographs? In addition to the complexity of determining meaning through words, a large library of graphical assets would be needed in mathematical form. A recent TED video of PhotoSynth (at 3:40) actually suggests that these assets can be data-mined from tagged Flicker images using computer vision techniques.

In the course of posing this question and researching the practicality of it in 2002, I discovered existing research called Word’s Eye that utilizes a conversational interface to construct images. The technology is described in the research paper WordsEye: Automatic Text-to-Scene Conversion System, but more accessible descriptions and examples are available in the following Creators Project blog post, “Wordseye Is An Artistic Software Designed To Depict Language.”

The above is an example of an uncanny WordsEye rendering an scene based on a text description. The graphics were licensed from a library of 3D model and are transformed to fit into the scene. This can be taken a step further to produce non-photorealistic rendering effects.

The Computers and Internet of Yesteryear

The underlying experiences that we obtain from using computers and the Internet may not be as alien to prior generations as we may think. Things are faster and smaller, but not fundamentally different.

Many complex systems have been with us around for millennia albeit in somewhat different forms: the rule of law, sophisticated government systems, commerce and engineering. A complex system of check processing was possible from distances of 500 miles during the Middle Ages. Our forebears were just as smart as us. For instance, the ancient Latin language is more advanced and refined than modern English in its grammar and sophistication.

We know Charles Babbage at the “father of the computer” for having attempted to build a mechanical computer called the difference engine during the Victorian Era in England, but, some time ago, another ancient mechanical computer was discovered from a Roman shipwreck off of the Greek island of Antikythera dating around 100-150 BC. Scientists who studied using x-ray tomography and other techniques were amazed of its flawless manufacturing and high level of miniaturization and sophistication. One of the scientists speculated that these kinds of devices may have been quite common, because a whole chain of inventions would have been needed to precede them.

Early archaeologists were probably did not recognize such past technological advances earlier because the knowledge was lost through time and of high sophistication requiring the eyes and tools of a trained scientists in other disciplines. In the same way, future generations may not understand, much less reconstruct, modern-day computer chips due to the expertise and billion dollar expenses involved, were the technology lost due to world war or natural disaster.

In another working instance, the book Group Theory in the Bedroom describes the 160-year old astronomical clock of Strasbourg Cathedral, which is essence a mechanical computer and one that has not succumbed to the Y2K problems of modern computers at the turn of the century. The clock includes an vast eclectic set of features, among them,  for instance….

Wait! There’s even more! The clock is inhabited by enough animated figures to open a small theme park. The day of the week is marked by a slow progression of seven Greco-Roman gods in chariots. At noon each day, the twelve apostles appear saluting a figure of Christ, who blesses each in turn and at the end offers benedictions to all present. Every half hour a putto overturns a sandglass, and on the quarter hours another strikes a chime. Still more chimes are sounded by figures representing the four ages of mankind, followed by a skeletal Death, who rings the hours. And a mechanical cock crows on cue, flapping its metal winds….

With regard to the Internet, there were many analogous social practices in prior times. Card catalogs in libraries served the same function as search engines. Penny universities in 18th-century London mirrored the online communities of the day. Long before the era of email, the U.S. Postal Service delivered mail seven days a week multiple times a day. The high frequency of the postal deliveries compensated for the general slowness of technology. The book Victorian Internet: The Remarkable Story of the Telegraph and the Nineteenth Century’s On-line Pioneers details the revolutionary impact of the electric telegraph in nullifying distance and shrinking the world during the nineteenth century much as the Internet has done today.

In his argument against Internet Software Patents, Philip Greenspun invoked the argument that the important technologies of today were envisioned by the early thinkers well before it was even practical to develop. I think that this hints at the commonalities of our experiences across time.

The old timers wrote that we would have tens of millions of computers connected to the Internet, that we would be using those computers to support collaborative work, that we would be able to search for information that would have been digitized on a vast scale, that we would be exchanging digital multimedia information such as pictures or video streams, that there would be a glut of information and that advertisers would pay to get users' attention. The old timers predicted that hardware engineers would figure out how to make silicon-based integrated circuits ever more dense with transistors and powerful, that we would have vast memories, and that there would be computers in every home. The old timers wrote that most business would be conducted via computer network, that electronic mail would surpass hardcopy letters for person-to-person correspondence, that unwanted email would be annoying.

A commenter cites specific examples.

Regarding UI: In As We May Think (1945), Vannevar Bush described an interface that is stunningly recognizable as web browsing. Doug Engelbart's work in the '60s (from which sprang the GUI, as Phil mentioned) was single-mindedly focused on providing the best user interface for what he called "knowledge workers". Some of his UI features, such as those for condensing text passages for quick skimming, are still unmatched. Direct manipulation showed up in Ivan Sutherland's Sketchpad (1963), whose constrained drawing features are also still unmatched. Windowed UI and WYSIWYG editing came with the Xerox Alto (1973). Even today, Photoshop and its clones still use the UI invented by Bill Atkinson for MacPaint (1983). And many believe that Atkinson's HyperCard (1987) is what the web should have been.

The two decades between Englebart's 1962 opus and the release of the Macintosh in 1984 were far and away the most fertile period of UI innovation. Most progress since then has been simply the wide-scale adoption of those ideas.

Regarding Moore's law: Look at the section "A Simple Vision of the Future" in Alan Kay's Early History Of Smalltalk. You will see a man who intimately understood Moore's Law, even in the late '70s.

Old-timers were able to conceive much of the digital experiences of today. Modern digital experiences are another reflection through more advanced technologies of fundamental human interactions that have always existed in some form.

Technology & Liberal Arts

Steve Jobs often attributes that the popularity of Apple products comes from merging technology with the humanities.

During the introduction of the first iPad, Jobs notes that "the reason that Apple is able to create products like iPad is because we always try to be at the intersection of technology and liberal arts, to be able to get the best of both, to make extremely advanced products in a technology point of view but also have them be intuitive, easy to use, fun to use so they really fit the users. The users don’t have to come to them, they come to the users. It’s the combination of these two things that has let us make the kind of creative products like the iPad. "

He repeated this theme during the unveiling of the second iPad as he proclaimed a new post-PC era. “It’s in Apple’s DNA that technology alone is not enough. It is a marriage of technology with the liberal arts and humanities. The competitors we see it as a new PC market. That’s not the right approach. Tablet is a computer that needs to be easier to use than a PC and should be more intuitive.”

As emerging competitors in the tablet space have attempted to one-up Apple with better “specs,” Apple simply ignores their moves, instead talking about products like GarageBand in the iPad2 launch to enable users to produce studio-quality music without effort. Each product launch features an exciting consumer software element like iMovie for iPhone 3GS, FaceTime, or Siri that reaffirms the human element in software. Apple products are beautiful, fun, personal, and magical. It just works.

I am reminded of a post “Apple is professional, the web is amateur,” praising Apple’s craftsmanship and show of love in its software; after reading the post, I played with the iLife suite and was completely stunned with the quality of websites that could be created with iWeb. (In contrast, Microsoft FrontPage was the surest way to produce an amateurish webpage as if none of the developers designed webpages. My encounter with Dreamweaver in 2000 was a “wake up” moment in the mediocrity of some of Microsoft applications.) As opposed to Android and Microsoft commercials that push vague, unauthentic, corporate branding messages, Apple’s products speak for themselves front-and-center in commercials with their impeccable beauty and magical qualities, whether it’s the richness of applications (especially those augmenting reality using phone-based sensors or tapping into web services like OpenTable), understanding of natural speech, or video-based calls.

This stance of melding humanities into technology harkens back to the Steve Job’s launch of the “Think Different” campaign, which shifted Apple’s marketing focus from technology to values, which is a passion.

The Apple brand has clearly suffered from neglect in this area in the last few years and we need to bring it back. The way to do that is not to talk about speeds and feeds; not to talk about MIPS and megahertz; not to talk about why we’re better than Windows…

Our customers want to know who is Apple and what is it that we stand for, where do we fit in this world. What we are about isn’t making boxes to get people to get their jobs done, although we do that well, we do that better than almost anybody in some cases. But Apple is about something more than that. Apple at the core, it’s core value, is that we believe that people with passion can change the world for the better.

In the recent CBS interview , Jobs is taped saying that Microsoft never had the humanities and liberal arts in its DNA, that they are a pure technology company. He also believes Google is turning the same way.

Online Courses

I have been regularly sifting through course material (syllabi, presentations) in MIT's publicly accessible OpenCourseWare website since the program was launched years ago.

Earlier this year, I took a further step and started delving deeper by approaching one of the courses as a student. The courses in question are graduate courses, 6.972 Algebraic Techniques and Semidefinite Optimization, and 6.883 Program Analysis in the Electrical Engineering and Computer Science Department.

I purchased some of the suggested texts from Amazon.

• Cox, D. A., John B. Little, and Donal O'Shea. Ideals, Varieties, and Algorithms: An Introduction to Computational Algebraic Geometry and Commutative Algebra. New York, NY: Springer-Verlag, 1997. ISBN: 0387946802.
• Mishra, Bhubaneswar. Algorithmic Algebra (Monographs in Computer Science). New York, NY: Springer-Verlag, 1993. ISBN: 0387940901.
• Sturmfels, Bernd. Solving Systems of Polynomial Equations. Providence, RI: American Mathematical Society, 2002. ISBN: 0821832514.
• Yap, Chee-Keng. Fundamental Problems of Algorithmic Algebra. New York, NY: Oxford University Press, 2000. ISBN: 0195125169.

I have been developing my static analysis tool without taking formal course, although I did review a number of lecture slides and academic papers. The reading list from a syllabus of another program verification course led me to purchase Logic in Computer Science (Modeling and Reasoning about Systems) and Software Abstractions, which after a couple days of reading, allowed me to come to understand the major approaches used in program verification including model checking and temporal logic.

The impetus for my self-study was my frustration with using the Internet as a resource for  learning. While various sites like Google Scholar, CiteSeer, and ACM Digital Library are valuable for reading up on latest research and techniques, and many detailed lecture notes and readings for introducing computer science theories are available in PDF, learning about established approaches at the graduate-level over the Internet is inadequate (look up Grobner Bases, for example). The Internet in such cases is not a good substitute for university courses in which material is selected, organized, and designed for pedagogy.

I uncovered tricks for reading through entire contents of a book though A9, Amazon's book search engine, but admittedly prefer, Google Books Search which offers substantial excerpts and previews of many academic publications such as in modal logic, hard to find even at a university book store.

I discovered later this year the University of Washington professional masters program in computer science has video taped lectures online for all their master's course, a practice that I assume was funded by local employer, Microsoft. The site includes a Conference XP web viewer that conveniently synchronizes slides, video, and agenda for remote listening. I had at one point considered applying for a UW MSCS degree in 1996, when the program was just starting with approximately 40 students, but the course offerings then were limited, and not in areas that I was interested in (ie, Transaction Processing). The program seems to have grown significantly larger over the decade since.

My goals have since evolved so that I might actually try something more ambitious, which is to gain exposure to the whole range of courses lectures in computer science, mathematics and other disciplines that I am interested in.

I don't think that my undergraduate education was as well designed as it could have been, but it might have been through the fault of my own not interacting with my advisers more. The ease of access of university courses is such an advantage for college students coming in today. Had I been a student now, I would have learned material online before taking the course, allowing me to decide whether I want to reinforce the learning and enroll in the course.  I could also listen to multiple courses taught by different lecturers to acquire a different perspective on the material.

Symbolic Ray-Tracing

I thought of an approach to ray-tracing that could result in faster performance using symbolic evaluation. I mention it here to illustrate the benefits of thinking symbolically and also because I don't see myself writing a ray tracer anytime in the next decade.

Images typically contain stretched out areas that correspond to the surfaces of individual objects. While each pixel in an area may have a unique color value, all of the pixels may easily computed by a single, simple function, even for textured surfaces. In theory, the applicable area of a function could be extended to the full dimensions of the image by using conditionals, but such a function would be unwieldy. 

Instead of calculating a color value for each ray we shoot out from each screen pixel, we could produce a partially evaluated function that returns a color. (This could work recursively in the event of reflected surfaces.) The computation for a single pixel would suffer, but the function could be reused to fill out the area occupied by adjacent related pixels, which also share the same function. Search and anti-aliasing costs for these pixels would be eliminated.

One approach to area detection is to produce a second function, which returns a boolean value indicating whether the first function is still valid for a given point, based on the information gathered from intersection tests of the original pixel. The second function basically serves as the boundary test for the flood fill operation. With this approach, we have the choice of making our first function a compiled function constructed from closures, a partially evaluated function represented as data, or a combination of both. Compiled functions might be faster, but data representations, being symbolic, could produce exact results.

Since this approach reduces work for typical images, I suspect that high quality images could one day be produced in the same amount of time that lowest quality images currently take without special hardware. 

LISP

Randal Munroe posted some "XKCD" comics on LISP, which I thought were  especially relevant to my situation.

This one below drawn a while back is called ""LISP" and captures my fascination with functional programming and its remarkable ability to express simply and elegantly everything about the world.

This more recent one called "LISP Cycles" conveys my attempt to use the light side of the "force," functional programming, to overcome the dark side, imperative programming (and --shhh!-- singlehandedly defeat the evil empire in the process.)

Old School Programming

Scott Hanselman recently wrote about teaching children and kids to program the old school way by using the Commodore 64 emulator. It seems just recently that Zenzo, his 18–month old child, jumped off the cradle.

I wonder if old-school programming with direct access to the computer and the operating system is preferable to learning with scripting languages of today. What follows is my case for old-school programming, but scripting languages do provide a much better, functional programming language to learn from..

I first got into programming with the Commodore PET, followed by the Commodore 64. Like Scott, I would spend hours typing up long BASIC and machine language programs (written in hex) from various computer magazines such as Compute! and Run. It was then that I began programming full-time. I still remember 53280/1 as the addresses for changing the screen colors, SYS 64738 for rebooting the operating system. I still have most of the 6510 codes burned in my head. LDA was A9 (169), LDX A2 (162), JSR 20 (32), RTS 60 (96), and of course BRK was zero.

I wrote my own assembler and disassembler and used both to write primarily in assembly language for the next few years (near address location 40960 which was an unused section of memory), which was all before high school. I used my disassembler to decode and rewrite the entire 8K of BASIC ROM and parts of the 8K kernel back to source with meaningful symbols. I remember becoming mesmerized with how the 256 byte stack was used for parsing expressions. Even though processors were slow, linear search was used everywhere even during frequent operations such as changes in control flow and variable access. I eventually added my own extensions to the BASIC language to support structured programming and better graphics.

I also played around as if I was the operating system, disabling interrupts to create my own interrupt routines, which I used to implement a partial multitasker, an animation engine, as well as a rasterizer that bypassed hardware limits for 8 sprites. In the default screen mode, every character occupied one byte of memory for a total of 1000 characters in a 25x40 grid; the number of characters were limited to 255. I also replaced the default mode to bitmapped mode, which consume eight times as many bytes: This enabled me to support character styles (bold, italics and underline), independent background/foreground colors for each character, larger character sets, and integrated graphics. I also experimented with proportional fonts (based on automatic detection of character boundaries and bit shifting) and screen widths larger than 40 characters.

I wrote rather than purchased my own software, as, being a child, I had no money. I built a range of programs including a wordprocessor to figure out how things works; some of these programs were better than commercial versions, but I just did not know how to sell them. I did seriously think about whether I could one day develop and sell my own software independently. In college, I purchased a couple books on developing and marketing shareware.

Programming at an early age helped with my education. I often found myself exposed to college material as a result of my activities. At a self-pace program in my elementary school, I began taking some high school courses while in sixth grade. Because I was already comfortable with memory addresses and stack, I never had the slightest difficulty with pointers and recursion, when I encountered them in C and Pascal; they both seemed natural to me. (Back eight years earlier, when I encountered PEEKs and POKEs, streams of hexadecimals numbers inside DATA statements, and mysterious SYS statements in computer magazines, I did find myself confused.)

 

Fabricated Complexity

There is a quote in computer science, “the solution to a hard problem, when solved, is simple.” I don’t know who to attribute it to, but I have repeatedly found myself arriving at very simple and elegant solutions to hard problems—problems in natural language, in AI, and in application development.

Anna Liu mentioned a talk by Willty Zwaenepoel on research and fabricated complexity.

He spoke of "Fabricated Complexity" - and basically about his observation that researchers often over complicate issues to make them seem 'interesting and novel' and to be accepted by the academic peer review process, while real practical/applicable ideas that lead to useful innovations often are actually based on 'simple ideas'.

He also came to the conclusion that 'design by contract/stable interfaces' are the key to successful (maintainable) innovation, despite he and his team spent many years of building some of the most 'sophisticated/complex' algorithms in distributed systems technologies, it was down to these simple software engineering concepts that would lead any innovation to wide adoption.

One paper that comes to mind is from the Spec# at Microsoft, Abstract Interpretation with Alien Expressions and Heap Structures. It took me a few readings to digest this paper. I gathered that “polyhedra domains” refers to the feasible region in the simplex algorithm, but much of the other content made more sense after going through related literature and course material.

What is more surprising is that I came up with a simpler, more elegant and more general solution than those mentioned in this paper. Perhaps, fabricated complexity leads to complex solutions. If simple, familiar ideas were used, would our mind be able to discover more associations with other related ideas? There may also be a greater tendency to preserve the beauty of a system when the components themselves are beautiful; when not, anything goes.

In economics, unions effectively drive up wages while limiting employment. Professional organizations maintain high levels of income of their highly-paid members by creating legal barriers of entry to new (usually younger) entrants. They lobby the government to impose stricter requirements for licensing, while, at the same time, urging grandfather clauses for existing practitioners. New interns must undergo many years of schooling, learn a new vocabulary, and work hours with low pay for a number of years. The same holds especially true for researchers of academia. 

I am not making a value judgment here; such practices might attract only the most dedicated people and also improve quality. We don’t want to reward those who only see the monetary incentive, but are not willing to put in effort. For the most part, the tendency for professionals to sharply divide the world between “knows” and “knows-not” is unconscious but convenient.

Just as professionals introduce a more complicated vocabulary, software companies often come up with complicated names in their products and libraries when simple ones would do. Since computer programming is so broadly applicable and valuable, an arcane vocabulary in this industry does not serve us well. While it’s not as basic a skill as reading and elementary mathematics, it ranks with business vocabulary, which is more accessible than the vocabulary of other professions.

Apple has always used friendly names in developer APIs. In contrast, Microsoft often unnecessarily complicated its API, especially COM, with cryptic names and hungarian notation, unintentionally driving users to the Java space and other platforms. Perhaps, this is partly because the architect of COM/OLE used to be a high-energy physicist from Oxford. His influence can be seen through the use of physical terms like source and sink in some COM interfaces. I once spoke to an OLE dev lead, who remarked that OLE development was incompatible with a short development time. It became clear to me that Microsoft APIs were unconsciously designed for other large software companies, most of which have since been vanquished by you know who.

The .NET Framework, especially with the help of the FX tool, enforces that the name of every type and method can be found a certain dictionary. Because it was designed for multiple languages, it had to serve the lowest common denominator; it had to be easy to use by the VB developer. This I think is one of the many reasons for its success.

One problem with functional languages comes from its heritage in academia. Hence, newcomers are often intimidated by the unfamiliar terminology, which actually refers to simple ideas. Functional programming languages look hard or too mathematical, when in fact they should actually be conceptually easier. The LINQ team has made many functional constructs dramatically more accessible by giving them names that sound more like conversational English. Operators like Map, filter, reduce, fold were changed to the names of their SQL counterparts such as select, where, sum, aggregate and so on. Terms like lambda expressions or closures might also become more accessible if described as anonymous functions or blocks. (Don’t try to figure out why closures are called “closures.” The origin of the name, which I have forgotten, is now meaningless today, but there use to be an “open” counterpart to the concept.)

Patents

Google just launched a search engine for finding patents. I typed in my name and discovered that I had been awarded a patent (assigned to Microsoft) for some obscure PivotTable feature in Excel.

In my MBA program, I attended some classes and seminars in a variety of laws including intellectual property law. I also used to regularly attend monthly sessions given by Washington Software Association to keep up to date on latest changes to law regarding software.

I have ambivalent feelings about whether I should seek patents. Software patents limit technological progress, and I would like to see the day when computers take over the world before I die.

There are a number of genuine inventions in my product that I think are patent-worthy. My needs are primarily defensive, though. I am not incline to sue anymore, especially the open-source community and small companies, and have even thought about opening up technology after I made a independently livable amount of wealth.

I could used this as a bargaining chip if I ever sold my technology. However, if that happen, I could get into the awful position of not being able to use what I invented. There’s a staggering amount of reuse between different areas of my product, and this is principally due to the inherently compositional nature of functional-style programming.

Incidentally, I have been contacted by the chief scientist of a leading source code analysis company, flowing with PhDs. He called my product “unique and interesting” and inquired about how my product works; he also mentioned potential business cooperation opportunities. Maybe, I hit some gold.

I can’t afford to actually buy a lawyer, but, since I am a do-it-yourselfer, I purchased last year Patent It Yourself by Nolo Press and other manuals. The law is constantly changing, so you need the latest copy. 

If I do go ahead, I may also buy Nolo’s software package, PatentEase. First, I would do a provisional patent application, which allows me to label my product as “patent-pending” and gives me a one-year window to actually file an application (I believe, but ask a real lawyer). Since I have been through the process before, have taken a number of basic courses, I think that I am prepared even though I am sure I will make some mistakes.

My motivation isn’t mostly money. I will probably never buy a large house or a car that costs over 40K. I inherited my father’s value system, which regards excessive, ostentatious wealth as vulgar. My motivation is to avoid meaningless work at a large corporation, to eliminate stress and to maintain a high level of freedom. I like the idea of staying a small company. My motivation is also intellectual—to explore the unrealized possibilities of computer, to find that intersection of human and computer intelligence.

Lego Programming

Joel reviewed a book Beyond Java, and, in his review, he enthusiastically recommended an essay by Fred Brooks called "No Silver Bullet: Essence and Accidents of Software Engineering." He recently mentioned it again in his post Lego Programming. Brooks wrote the Mythical Man Month, which was really the first software engineering text. It was remarkable in identifying surprising asymmetries in software development. For example, Brooks identified the network costs in adding more developers to a project and dramatic disparities  in individual developer productivity (eg, "adding manpower to a late softer project makes it later"), but he also made a number of forgotten poor predictions in the same book, some of which he confesses to in "The Mythical Man Month After 20 Years"  such as "I am convinced that interactive systems will never displace batch systems for many applications."

I have written about Silver Bullets in the past and emphatically feel the widely regarded author to be irresponsible and premature in his assessment of there being no silvery bullets, which is leading many developers, not the least of which is Joel, to be unimaginative and pessimistic of advances in software development.

For example, Brooks asserts in the start of his essay this bit of false wisdom:

There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.

That assertion turns out to be pure nonsense, amply disproven by numerous advances in IDEs, languages, frameworks, componentization over the past few decades. Our expectations of software and our ability have risen. A year of work takes a month or a month of work takes a day. An order of magnitude improvement usually results in major qualitative changes, often resulting in an existing lengthy project becoming a short task item or a new project suddenly becoming feasible, such as when end users start writing applications (using scripting and RAD tools) that were once exclusively the domain of IT.

The net effect is that we often don't consciously recognize tenfold improvements in productivity. We forget how hard it was to program decades ago. Consider developing a game for the simple Atari 2600 gaming system back in the early 1980s.

I see the driving force towards tenfold productivity as the move to more declarative and compositional approaches, be it through functional, object-oriented, and component-based programming. Kinda like Lego.