Media Content

Media Content

Papers

Here is a collection of Papers, Articles, Whitepapers and eBooks that I’ve authored over time. The opinions expressed in these works are mine, and not necessarily those of my employer at the time (GlobalLogic from April 2009-October 2025) or the publisher for published articles. Any trademarked terms that I reference in passing are the property of their respective owners, and my mention of them does not necessarily imply any endorsement or relationship between me and them.

16-Feb-2023

Software Engineering in the Era of Creative AIs

The short eBook above describes my thoughts from early 2023 about how Software Product Development would be affected by what’s now called GenAI. The basic message is that it would be accelerated dramatically, with a “sprint” that formerly took a team of multiple people 2 weeks to execute in 2022 eventually being implemented by an AI overnight. What remains for us humans to do in this scenario is concept design, requirements validation, and the implementation validation process (“I got what I asked for but did I get what I really wanted?” “Did the users get what they need?”). Development work is organized in a drastically streamlined and accelerated–but still recognizable–Agile process.

This piece was written just a few months after the November 2022 public rollout of ChatGPT. The term “GenAI” had not yet come into widespread use when this was written, so I use my own term for the new technology, “Creative AIs”. Needless to say, my term did not catch on. But now, several years later, I still believe these predictions are valid. In fact, many of them are already coming true.

9-Sep-2019

The Economics of Digital Transformation

The eBook above describes approaches to digital transformation, and why to choose one approach over the other–that’s the ‘economics’ aspect of this. I use the word ‘economics’ in the sense of making a wise allocation of scarce resources in the presence of competing constraints and priorities. This includes not just financial resources, but people, intellectual and emotional / political ones as well. I talk about why transformation initiatives frequently fail, or only succeed partially. And I conclude with a discussion of the ROI of transformation initiatives–and the risk of not transforming in the face of disruption.

This was written about 3 years before GenAI surfaced as perhaps the most disruptive ‘digital’ technology of all. The lessons about dealing with disruptive technologies described here are very much applicable to GenAI and to technology transformation generally.

26-June-2016

Presentation on my career to the National Youth Leadership Forum on Engineering & Technology at UC Berkeley

I was asked by a former colleague to give a presentation on my career to a group of about 300 inbound college students hosted by the National Youth Leadership Forum on Engineering & Technology at the University of California at Berkeley. This presentation goes all the way back to my own teenage years, when I was their age, and discusses why I made the career decisions I did along the way. I put a fair amount of focus on my 4+ year relationship with Steve Jobs because I knew it would be of interest to this group. Images gathered from the Web, where present, are the property of their respective owners and will be removed or replaced on request.

1-Jun-1993

How We Tested NEXTSTEP for Intel Processors, NEXTSTEP In Focus, Spring 1993 (Volume 3, Issue 2).

http://index.rhetori.ca/docs/in-focus/1993_spring/how_we_tested/index.html

I joined NeXT in early 1993 and founded their first formal quality and testing organization. “Quality” in this context included engineering ownership of an automated deployment process that today we’d class as part of DevOps; tools development for a subset of the tool suite (defect tracking system, test automation, etc.), development process, Lab management, and, of course, actual testing of NeXT’s advanced Unix-based operating system and associated tools (email, etc.). In fact, in my final year as head of the quality team, before transitioning to an full-time engineering (development) management role, I was able to make a profit through our sales of testing and defect tracking tools to clients–probably one of the few times that has happened in the industry.

While NeXT’s product quality was already top-notch when I joined, the problem Steve Jobs asked me to solve was speed. In my first meeting with him, he said that it always seemed to take 18 month to ship a release of the then 5.5 MLOC NeXTStep operating system. He wanted to be able to get it down to 6 months. Building on the iterative development style that NeXT already had in place, and collaborating with an exceptional engineering and product management team, we got the release frequency down to 4 months. That was faster than our customers wanted to upgrade, given the then-manual nature of the OS-upgrade process!

When I worked at NeXT I published a number of articles for NeXT’s print publications. This is one of them. It briefly describes our approach to testing NeXT’s first release supporting non-Proprietary Hardware, NeXTSTEP 3.1 for Intel. This release ended up being monumentally important because (a) NeXTSTEP’s support for Intel processors was a key reason that NeXT was acquired by Apple in 1996 (leading to Steve Job’s eventual return to Apple and the subsequent success of the company), and (b) NeXTSTEP for Intel ended up being the foundation for Apple’s subsequent OS X and, arguably, other offerings such as iOS. The hardware independence we introduced in this release has positive effects felt even today in OS X.

1-Apr-1993

“Determining Software Quality”, Computer Language, Vol. 10, no. 4, pp 57-62, April 1993

In this article I discuss using the defect discovery rate (“DDR”) metric to provide a concrete assessment of the quality state of a software product under development, and to support concrete metric- and financially-based ship decisions. This was written while I was at Rational (now IBM), though it was published in Computer Language Magazine (later Dr. Dobbs Journal) after I’d already started working at NeXT computer. I introduced this metrics-based technique at Rational as well as NeXT, and it was used as a key input to our quality-based release decisions.

Because I live in Silicon Valley (and this was pre-Web), when the physical magazine was published, copies were actually sold from the magazine rack of my local grocery store! It was exciting to see the physical magazine for sale on the magazine rack, alongside other then-popular computer-related offerings, especially because my article (“When will it ship?”) was mentioned on the front cover.

NOTE: I was unable to locate a copy of this on-line, so this is a scan of a physical copy of my article in the magazine. If you are the copyright holder and want me to take it down, please let me know.

18-Oct-1992

Preliminary Defect Data from the Development of a Large C++ Program (Experience Report), OOPSLA 1992 (ACM)

https://dl.acm.org/doi/abs/10.1145/141937.141952

At the time it was written (1991-92), at about 230,000 lines of code (230 kLOC), Rational Rose 1.0 was one of the largest object-oriented programs (C++) that had been developed up to that point. In this paper I talk about insuring software quality in an iterative development methodology, the then-new concept of using the defect discovery rate to measure current and predict future software quality, and I discuss which characteristics of the system have the highest predictive value for defects. For the latter: It turns out that interfaces between components are, of course, error prone–but also that the elements of the system with the most dependencies on them tend to have fewer defects. In other words, if you look at the dependency graph of the software, the “leaf” nodes with few or no dependencies, such as the UI, tend to have the most defects, while the foundational / core nodes have the fewest. This is because, I believe, the ‘core’ components on which many other components depend tend to be exercised the most (and receive the greatest care), exposing and driving out bugs.

I presented this paper in person at the 1992 OOPSLA conference in Vancouver Canada. The conference room must have seated over 1,000 people, and while not all of the chairs were occupied, it was still a heady experience giving this talk at a very prestigious ACM gathering.

I wrote the paper when I was at Rational (now part of IBM), leading the quality team for the Rose 1.0 project. This was my first time leading a quality group, as my career up to that point (10 years in) had been focused on architecture and development. I got the job at Rational, considered a highly elite Silicon Valley company at that time, because (a) Rose was a tool for software architects, and I had experience as an architect and developer, not ‘just’ as a tester, and (b) I had previous experience with OO and C++, from my work as a consultant at Borland.

My time at Rational was important for my subsequent career in multiple ways:

  • Code Generation. I’d used algorithmic code generation in my work as a consultant to help create a C++ Compiler validation suite at Borland. But Code Generation was central to the Rose 1.0 project. The tool itself was designed to generate code from architecture diagrams, and I used a formal requirements definition that I created for Booch notation to generate a comprehensive syntax test suite for the product.
  • World-class team. The Rose 1.0 team at Rational was exceptional; truly an elite Silicon Valley team. This really taught me a standard of excellence that I applied in the rest of my career.
  • Iterative development. This was my first exposure to an iterative, round-trip style of software development, which had been pioneered and evangelized by the project architect, Grady Booch. Until then my experience, like everyone else’s at the time, had been with “waterfall” methodologies. This exposure to iterative development opened my eyes. Rose’s iterative development approach became the foundation of the Rational Unified Process (RUP). In fact the authors of the RUP process at Rational incorporated my input on iterative quality into the process definition. This was in the early 1990’s, before Agile had been formally invented.
  • Rational encouraged publications, such as the one here, and a subsequent magazine article I wrote.
  • My General Manager at Rational transitioned to NeXT Software, and is the one responsible for my recruitment into Steve Job’s company and, therefore later, Apple.
Read more: Media Content

1990

Debugging TSRs and device drivers, Chapter 17, Borland Turbo Debugger 2.0 User’s Guide, p. 257-265

https://archive.org/details/bitsavers_borlandturugger2.0UsersGuide1990_14115184/page/n271/mode/2up

After I was unable to secure funding for my time-ordering neural network startup in early 1989, I took my first-ever job in Silicon Valley (actually geographically in Scott’s Valley, which is nearby) later in the year. This was as a consultant at Borland, a very well known and well regarded software tools company at that time, and the producer of the first widely-used, commercially successful C++ compiler. I was assigned the creation of test suites for the more technical and mathematical areas of three of Borland’s marquee products. Specifically, I developed suites for the numerical algorithms of Borland’s “Quattro Pro” spreadsheet (a competitor to the then-ubiquitous “Lotus 1-2-3”, hence the name “Quattro”); creating a compiler validation test suite for the deeply nested and recursive functions of the Turbo C++ compiler; and the Turbo Debugger, where I focused on functionality to debug device drivers and TSR’s (“terminate and stay resident” programs, an early way to suspend a process in the background).

I was asked to provide technical input to the writers who were creating the User’s Guide for the TSR and Device Driver functionality of the debugger. Because these areas were so technical, the writers ended up using my input basically as I wrote it. While I can’t claim full authorship, these were very widely popular tools in their time, and I felt proud of my contribution.

19-Nov-1988

Temporal Ordering in Neural Networks

Abstract: Current theories of neural networks do not provide a mechanism to incorporate the time-ordering of stimuli into the structure of a neural network as a natural part of the network learning and recall process. This is a serious limitation of these models, both from the point of view of their application to problems which deal with temporally ordered stimuli, such as speech and motion recognition, and with respect to their ability to model biological brain behavior. This paper describes a biologically motivated three-dimensional neural network which associates and stores temporal order information with the applied stimuli in the network as an integral part of the learning process. Temporal ordering information is stored primarily in the propagation delay of neuronal signals. In the mammalian brain, such delays may result from interneurons or from the geometry of axonic and dendritic processes and their synapses. The model can be used to develop either a self-organizing network, or an associative network through the incorporation of pre-synaptic excitation and inhibition.

31-Mar-1989

Experiment / Implementation Plan to Demonstrate Time-ordering Neural Network Technology for Use in High-Quality Speech Recognition System

This post to the ‘Digitally Indigenous” website is the first time the “Temporal Ordering in Neural Networks” paper, which I originally authored in 1988, has been published. Back when I wrote it, my intent was to patent this idea and start a company using this technology; first for speech recognition, and later for other types of time-varying stimuli such as what we now call computer vision. However, I tried and failed to get venture funding, put it on the shelf, and moved on with my life. In 2002 I submitted this paper, with minor edits, for publication to a peer-reviewed brain-physiology-oriented journal. Though it attracted interest from the reviewers from an algorithm standpoint, it was rejected for that publication because the reviewers felt the approach did not have a strong enough biological basis. Specifically, some reviewers felt the delay times required by the model did not have an obvious analog in the brain..

The work you see here was self-funded by me, and presents a model for the recognition of time-varying stimuli using neural networks to form what I called a “matched temporal filter” or “timenet” (though that name has later been co-opted by project management software. I’ll use “timenet” here for brevity, but please note this is not to be confused with the current user of this term.). The use of a holographic “matched filter” mechanism to recognize spatially distributed stimuli, such as letters on a page, was already well established when I wrote this in 1988; though not yet applied to neural networks, as far as I knew at the time (or know now in 2025 for that matter). In this paper I extend the holographic matched filter concept as well as the neural network approach to the time domain.

I did the bulk of this work in 1987 and 1988, and then spent the early part of 1989 trying to get it patented and funded. I hired a lawyer–always a smart first move–and a qualified reviewer who read, understood, and “time stamped” my work to establish precedence. I then went and pitched the VC’s on Silicon Valley’s legendary “Sand Hill Road”. This was quite a learning experience in itself. I had my academic credentials, but I had just moved to Silicon Valley a few month before (I moved here in August 1988) and had only a 6-year work history at that time. Nonetheless, the VCs took me seriously. They listened to my pitch (which I delivered using overhead transparencies, as I recall), they hired a technical expert to do due diligence, and then they made a thoughtful decision. It was “no”, which was tough for me, but I felt heard and I understood the decision from a VC perspective.

The paper presents the structure of the timenet model itself. My training approach for the application of the model to speech recognition is outlined in the 31-Mar-1989 “Implementation Plan” I presented to the VC’s. The concept was to train the network using the same approach that human babies use to learn language. My hypothesis, based on observing my own children as infants, was that children learn speech by listening, and then by trying to imitate the speech sounds they hear. Layers of association are built up by correlating first the raw sounds, and then associating those sounds with other stimuli such as the face of a person with the sound of “ma-ma” or “da-da”.

We know for a fact that the ear uses a Fourier transform-type mechanism to decompose sounds into a time-varying spectrum of frequencies. My training hypothesis was that the infant’s brain associates those spectra to the specific muscle movements required to produce a similar sound–that is, they learn to use their own infant vocal tract to generate a similar time-varying spectral profile to those they heard (though, of course, transposed in frequency due to the different size of the vocal tract).

Linguist Noam Chomsky, in his academic work “The Sound Pattern of English“, and related work done by others, produced a model that related the muscle movements of the vocal tract to the speech sounds (phonemes and more complex structures) the vocal tract produced. My training concept was to use a synthesized model of the human vocal tract (called an “articulatory synthesizer”, which already existed at that time) to “babel” (make pseudo-random speech sounds), and use the timenet to listen to the human speech sounds produced. The time-varying Fourier transform resulting from listening to the randomly-generated biologically-possible speech sounds (“ma”, “pa”, etc.) would be mapped to the physical muscle movements needed to produce those sounds, training the timenet. The timenet would therefore learn to relate the time-varying spectra it ‘heard’ to the physical vocal tract actions needed to produce the corresponding speech sounds, laying down a foundation layer for physiologically-based speech production and recognition. Subsequent layers of time-varying correlations of speech sounds would be built up layer-on-layer in a similar way, with the time correlation used to train the timenet. The result would be a fluid mechanism to ‘understand’ and produce human speech.

Given that GenAI has brought neural networks into the mainstream recently (as I write this in 2025), it may be surprising that they were already well-developed field of study by the late 1980’s, and even before. While I had a scheme to use then-available digital signal processing (DSP) chips, the compute power needed to train and later process complex speech and natural language in real-time probably did not exist at that point to make this practical. While time has proven that the neural network approach is a spectacularly good one, it was a long time before that happened. In 1989 the VC’s felt, probably correctly, that this was too much of a research project for them to fund, given the number of hurdles that would need to be overcome to get to a revenue-generating production system.

Current (2025) language processing capabilities have gotten pretty good using brute-force computational methods, though of course the processing power available today is orders of magnitude more powerful as well as far cheaper than it was in 1989. I can’t help that thinking, though, that even so a more biologically based self-learning approach COMBINED with brute force may help solve some truly difficult remaining problems, such as AGI (Artificial General Intelligence).

Pages: 1 2