Most sane people avoid version one of software because they don't like being guinea pigs. Keep version one simple and save all the extras for version two and three.
I have no idea why we were out there. Graham, though seasick, did manage to stand watch. My wife stoically hung on and cooked despite the battering waves. Sudden squalls attacked unexpectedly, the wind increasing from 30 knots to 55 in a matter of seconds. Voyager heeled far to port, the portholes and deck underwater till I wrestled the sail down.
We weren't having a lot of fun.
Then the vane, a mechanical device that steers by the wind, failed. The electronic autopilot was overpowered by the rough conditions, so we steered for three days, each of us at the helm for two hours, off for four, night and day.
Yesterday we arrived in Bermuda, after sailing 800 miles southeast from Baltimore. Yet we're really headed north, to Nova Scotia and Maine. Why take this outrageous detour that'll add perhaps 1,300 miles to the trip?
The ostensible purpose is to check out a new technology called AIS, or Automatic Identification System. International law that took effect this year requires all ships over 300 tons to automatically broadcast a lot of information, including their name, position, course, and speed a few times a minute in a digital stream on marine VHF frequencies. These vessels also have a radar-like display that displays such information from all other ships within 20 or 30 miles, all to help avoid collisions.
My biggest fear while sailing far offshore is being run down by a fast-moving ship that can't see my little boat. Over the years I've added various bits of electronics, such as radar, to warn of nearby traffic. But radar takes too much power to run continuously, and rain squalls obscure even 800 foot fast-moving metal monsters. A radar detector sounds an alarm when it detects signals from any vessel within 10 miles or so, yet nearly half of the ships we see don't run radar in good weather. So when NASA Marine (www.nasamarine.com) released its AIS system for small craft, I bought an early version. It consumes a bare 80ma and sounds an alarm when detecting any vessel within a programmable range.
We went to Bermuda to have a long offshore run simply to see how well AIS works on a small boat. The island's famous rum swizzles had no influence on our decision to choose this destination, of course.
Most of us techies are early adopters. When confronted with cool, reason yields to passion. Yet having all too often rushed a new technology to market, we embedded folk know that version 1.0 is always a poor early iteration sure to infuriate our customers. I found this AIS unit a perfect example of how marketing's drive to ship now sacrifices quality.
Although I'll dissect the unit's shortcomings, it is a fabulous and inexpensive piece of gear that flawlessly displayed the position of every ship we saw, with the exception of the three Navy frigates that followed us for 24 hours out of Norfolk, one of which scarily conducted live fire exercises three miles away. Unsurprisingly, warships don't care to advertise their positions.
We tore the unit apart out of the same curiosity that drove my mother crazy so many decades ago when she found her appliances half disassembled. It's not much more than a simple VHF receiver that feeds the digital stream into an 8051, with a 3 x 5-inch LCD to graphically show ship positions, plus four pushbuttons whose function changes depending on operating mode.
I don't know the folks at NASA Marine, but can imagine the engineering discussions that resulted in the selection of an 8051. This low-end (about $350) product had to have very cheap manufacturing costs, so an 8-bit microcontroller was a natural choice. Me, I tend toward 8 bitters whenever possible as well. Yet in this case it was a poor choice. In a version 1.0 unit, engineering should have realized that marketing would invariably load versions 2.0 and 3.0 with lots more features that will surely overtax such a minimal microcontroller. Can you imagine how tempting that LCD display will be to the sales folks? “We have a customer who wants to play video games on the thing! I promised another we'll ship a version that plays DVDs by next week.”
Not that long ago designers wisely matched horsepower to the scope of the application. But today feature-hungry consumers, aided and abetted by marketing departments clueless about real costs, evolve beautifully simple and elegant systems into wart-covered elephants that barely resemble the original concept. All too often those warts arise from frantic designers cramming insanely complex features into a tiny address space already chock-full with the system's bare essentials. As an EE trained to minimize bill-of-material costs, it pains me to make the following recommendation: when at all possible, especially on a system with a graphical display, use more processor than you expect to need. Version 2.0 will surely consume the excess CPU cycles and memory.
On this AIS the 8051's limited RAM makes even version 1.0 behave poorly. When more than one ship is in sight the user presses the “data” button to scroll through information broadcast by each vessel. Select one, and the right side of the LCD shows that ship's name, position, speed, and more. Press “data” again to select another target and wait. And wait some more, for up to a minute till the ship transmits again. For the processor has so little RAM it cannot store the information transmitted from all ships in the vicinity. With more RAM the system could suck in data from every vessel, and immediately update the display as the user switches between ships.
Were people more patient years ago than today? In the Vacuum Tube Era everyone expected to wait a minute or so when powering up anything electronic. Those tolerant times are long gone. Never make a user wait because of some technological limitation. Only version 1.0 products have delays. Version 2.0 won't, which, in this case, will require a complete redesign to add more processor oomph.
When I first tried the AIS in Baltimore harbor it showed several ships were on a heading of 511 degrees. 511? My immediate reaction was a chuckle; here's yet another buggy embedded system reporting insane answers.
A very short FAQ in the manual, though, tells a different story. Apparently the unit displays this odd result when a ship, for some reason, doesn't transmit course information. At least the manual reports this peculiar mode. But as a rule, never present stupid results. When any output confuses the user the system is poorly designed. I'm sure version 2.0 will show something more reasonable, like “none” or “- – -.” I can't imagine why the designers chose to show such a strange and arbitrary result.
(Last year I saw a huge side-of-the-road billboard displaying the temperature on a fine September day: -196 degrees. This was another case of designers making poor decisions. Better to bound the possible output values. If the code generates an impossible result, perhaps due to a hardware fault, it's far better to show nothing, or perhaps “HELP ME!”)
And then there's the unit's manual, a version 1.0 bit of work if there ever was one. Seven microscopic pages cover everything from installation to operation. Although AIS's user interface is pretty intuitive and a credit to the designers, one or two modes continue to elude me. One of these days I'll spend some time playing with it to finally master those features. But it's always a bad idea to make the user guess. This is the communications age, and good product design requires a manual that communicates clearly and completely.
I wish the manual's shortcomings were indicative of a version 1.0 device, but my boat—and my life—are filled with embedded apps whose documents range from completely inadequate to almost laughable.
Figure 1 shows both the AIS and a Link 10 from Xantrex Technology (www.xantrex.com), which monitors the condition of Voyager 's twin golf cart batteries. It's a remarkable unit that works flawlessly. Clearly it's well past the version 1.0 stage.
But the user's manual is awful. Also printed in small size that doesn't fit in any normal filing system, it's full of cryptic proclamations like “The Charged Current % times declared Battery Capacity MUST be GREATER than the minimum current at which the charging system maintains the batter, or turns off.” Huh? So little care was taken with this document that even the copyright notice doesn't meet legal requirements. One function I use pretty regularly is so poorly described I've had to write out the procedure on the margin of the appropriate pages.
Don't treat the user so badly. He experiences your product through its features and documents. The code we slave so long over is sort of like an engine's cooling system: critically important but invisible. Hire one of those poor English majors who is dejectedly pursuing a career in the fast food industry to create a manual that thrills, rather than torments, your customer.
A sailboat runs off batteries for days, between engine-charging periods. Most sailors use quite elaborate alternators and voltage regulators to put amps back in the batteries as efficiently as possible. Voyager's regulator is from the same company that makes the monitor I've just described, and the manual is equally obscure, suggesting that the company has a policy of deprecating the docs.
Yet that regulator, like the battery monitor, is brilliantly engineered. It's completely potted in epoxy for waterproofness, a highly desirable feature in the salty sailing environment. LED displays show clearly through the clear potting. To select various operating modes and set parameters the user holds a small magnet, cleverly supplied with the unit, to activate a reed switch buried in the epoxy. A simple interface using just this one switch lets one enter many dozens of numeric values and more. Kudos to those engineers.
Voyager was built in 1977 and some of her equipment is original. It's fascinating to see the evolution in the nature of products by looking at these electronic accessories. Her original depth sounder shows depth. Nothing more. The old knotmeter, recently replaced, displayed speed, period. The replacement shows water temperature, maximum, average, and minimum speed, plus another dozen or so readouts.
This winter I replaced the original radio. The new unit, a marvel of embedded systems engineering, communicates as the old one did and offers so much more. So much, that I'm still trying to figure it all out. The thing even displays a happy fish icon when the barometric pressure is suitable for angling. Cool, I guess. But surely the embedded systems revolution has made products of all sorts so feature-rich that version 1.0 releases tend to be buggy, hard to use, poorly documented, and sometimes not so well thought out.
No one is more important to a project than the customer. He or she puts food on our table, clothes our kids, and pays the mortgage. Design to delight first, rather than to cram lots of infrequently used features into the system. An explosion of features can wait for version 2.0 and 3.0.
Jack Ganssle () is a lecturer and consultant specializing in embedded systems' development issues. For more information about Jack .
Jack, I always enjoy your columns, especially when they involve sailing stories and/or your view on products.
Anyway, regarding the 511 degrees… I bet they use 9 bits to represent the degrees (8 bits would only cover 0-255 degrees), and the 511 is just the “all 1s” bumper value….
– Dan Smith
Software is a comprimise.
On one hand people are scared of version 1.0 software
on the other hand
… this quote I think says it well …
“Programming today is the opposite of diamond mining. In diamond mining you dig up a lot of dirt to find a small bit of value. With programming you start with the value, the real intention, and bury it in a bunch of dirt.” ( I think someone at Microsoft).
– Tim Flynn
Developers can learn a lot from being on the other side of the counter. Some companies I have worked for have had a policy encouraging direct communication between developers and customers, while others banned it!
I'm currently writing a little software utility which will be really useful to a lot of engineers. I started writing it for my own benefit, so I'm the developer, marketeer and customer, and it will be REALLY simple. I'm a bit unsure about when to release it, and I'm sure a lot of potential users will be put off by “Version 1” status. I guess I'm going to have to find some tame, beta users.
– Oliver Sedlacek
I think Version 1.0 is a special case of the same tub you've been thumping for years, Jack: software quality stinks and it's up to us to fix it. The reasons may vary from version to version, but the end result is the same:
Version 1: A combination of inexperienced developers, overactive Marketing imagination, and an upcoming show (which I think you touched on before) make for a poorly defined, loosely coded, and insufficiently tested product.
Version 2: Results of beta testing (i.e. warranty returns and customer complaints) and experience gained by the development team reveal the need for a new release to fix some serious bugs. Marketing is delighted at the opportunity, since now we can include new features that potential customers have requested. (In Marketing's defense (and I can't believe I'm doing this), you can survey users all you want about how they'll use a device or what features they want, but all you'll get is a description of what they've been using – probably your competitions' product. You won't get any concrete answers until you put something in customers' hands and they actually try it. Any complaint that begins, “I can't use this because…” is a real-world requirement, and should be addressed.) Bugs get fixed but new ones are added. New features strain the existing architecture but are shoe-horned in with some compromises. The code is rushed through testing because a huge order is being held for the new firmware. Discussions about shipping the existing hardware and following up with a firmware upgrade disk next month begin.
Version 3: The product is mature and a commercial success, but some upstart competitor has announced a cheaper alternative. We can't be content to out-feature them; we have to beat them on price too. Begin a panic cost reduction redesign, with yet more features – any features – added to pad out the brochure, and get it to the market before they cut too deeply into our share. (The fact that all the competition every shipped was data sheets isn't noticed until we've built and shipped several hundred door stops.)
– Dave Hinerman