Chris Lanfear from VDC systems asks
FSMLabs has the product line, but lacks the market presence and awareness that other companies have invested in with venture-backed capital. We believe the company has largely bootstrapped itself over the years and while this conservative approach has a number of benefits, it is difficult to achieve the market presence of a MontaVista that way. That said, the problems that MontaVista appears to have are only compounded by investors with high-return expectations. Maybe the folks in Socorro have a better plan?cite
And that’s reasonably on target. We have grown slowly, invested in technology and engineering, remain relatively clueless about “market presence”, and have a pretty straightforward business operation (make products with some compelling technical advantage, sell them at a profit, sell support at break even or better, move towards more integrated products, leverage the open source
base so we don’t re-create commodity stuff, … ). Chris underestimates the number of mission critical applications using RTLinux, but see “clueless about marketing” above. Our sales guys have to sell the stuff on price and quality – a daunting task in this market.
Chris mentions our lack of VC investment, and one of the reasons we have not taken VC investment is that we have resisted pressures to make up stories about fabulous wealth in blinks of an eye and “innovative” business models that create profits from “market presence”. We sell highly complex, technical software that requires a long slow engineering and test process. Our “business model” of looking for compelling technical advantage pushes us towards hard problems (you can’t obtain a compelling technical advantage on work that can be done easily).
In a previous note I objected to venture capitalist Guy Kawasaki’s requests (demands) for shallow and glib sales pitches in PowerPoint, but Professor Edward Tufte is also asking for sales pitches, just ones with more sober disguise. When you read “My other models for NASA are Feynmanâ€™s lectures on physics, and the A3 page (or 11 by 17 in) folded in half” the excellent quality of the writing helps slip by the emotive appeal to the form of Fenyman’s lectures and crisp clean sheets of paper as if something were implied about the quality of the content. Any University library computer science section can supply an apparently infinite number of illustrations of how perfectly good paper, verb predicate sentences, and beautifully typeset symbols can be employed to transmit vacuous nonsense. Continue reading “PowerPoint and RocketScience II”
The Sony DRM fiasco is due to a common failure of requirements management logic. If an engineered system relies on certain properties, whenever you add a new requirement, you need to check consistency. You have a boat that has EnoughCargoSpace and ReasonableEnergyCost and you decide to add the requirement CantLeak. So you encase the entire boat in a meter of steel. Amazingly the boat no longer meets its other requirements. The weightless nature of software encourages people to forget that there are inescapable tradeoffs. If you impose a rule “B: The DRM system is all powerful” then you have contradicted “A: No Software Can Turn Off Security.” DRM engineers need to come to terms with “Some of the properties of a computer are more critical than protecting IP.” In my drm paper (published in LinuxDevices in 2002) I discussed potential security and safety issues when DRM interacts with embedded software. It’s bad enough to open a door to virus software on home PCs, but imagine the effects in medical devices and elevators!
See also Moshe Yudkowsky on the ColdPlay story
Update: See also – no kidding.
Update: So how much of the Song BMG fiasco was caused by bad engineering practices and how much was caused by bad management practices? These two types of bad are often synergistic.
Update: Boing Boing covers continuing fallout.
Update: See the Linux Devices story on DRM
In American English, you can say that something is not too difficult by saying “it’s not rocket science.” We don’t have a good idiom for saying the opposite – that something is hard to understand, not bullet-pointable. Edward Tufte dislikes PowerPoint because it can be used in a way that obscures critical data under a pile of graphics and misleading bullet points.
My other models for NASA are Feynman’s lectures on physics, and the A3 page (or 11 by 17 in) folded in half. You can see where we’re at. If they would just write sentences, with subjects and predicates, rather than those damn bullet points.
At some of these organizations, a technical report is called a “pitch” and is presented in 10-15 minutes, or presented simply as a PP deck to look over, or shown as a one-slide executive summary, or circulated by email-attached PP slides for the cognoscenti. Some of that reporting is done in a crisis; the Boeing PP slides were prepared in 2 or 3 days when the Columbia was in trouble but still flying. ( cite)
Guy Kawasaki wants shorter, sharper, presentations:
a PowerPoint presentation should have ten slides, last no more than twenty minutes, and contain no font smaller than thirty points.
from Guy Kawasaki
I’m dubious that improving the technology or execution of presentations is a solution to anything. Certainly improving the technology of selling political candidates has not improved their quality. Kawasaki is asking for a short sweet pitch. He’s asking to be told a compelling story about how he can make lots of money fast. And the NASA bureaucrats wanted compelling stories about how they could complete the mission. Making the NASA presentations shorter and sharper would not have helped. Maybe the pitches tell Kawasaki what he needs to know – part of what he wants to know is whether the presenter is a good salesperson. Sales and sales pitches are part of how we communicate. But some things are rocket science or just as hard and for those things pitches are dangerous. For rocket science or the equivalent you need tough, demanding, focused presentations that painstakingly dig out the tradeoffs and uncertainties. These presentations don’t have to be dull, but they are too qualified and too complex to be good pitches. Compelling stories may not be true stories. Pitches that engage us emotionally may also lead us down the wrong path. Something may feel right but be wrong. I often ask for more detail, more caveats, more analysis both on engineering issues and business issues. In both places, short sweet and compelling can mean – too good to be true.
I’m biased of course, because many of our competitors have much better pitches than ours. Fortunately for us, although not necessarily for everyone involved, physics trumps salesmanship in our field – eventually and sometimes spectacularly. (There’s a followup to this note here)
Holloway  points out that the typical argument in favor of formal methods (that software is bad, unique, and discontinuous; that testing is inadequate; and that formal methods are essential to avoid design flaws) is logically flawed, and unnecessarily complex (in logical terms). He proposes a simpler argument, which is both simple and logically valid: software engineers want to be â€œrealâ€ engineers; such engineers apply mathematics; and since formalÂ methods is the mathematics of software engineering, software engineers should use formal methods.
Can you imagine Maxwell or some advocate of his making a similar argument about why electrical engineers should use electromagnetic theory? TheÂ cyclical argument here depends onÂ Â the declaration that Â “formal methods is the mathematics of software engineering”.Â No it’s not. The mathematics of some engineering discipline helps engineers solve actual problems in thatÂ discipline.Â