Slashdot Mirror

Edward Lorenz discovered that floating point truncation causes weather simulations to diverge massively back in 1961.
This was the foundation of Chaos Theory and it was Lorenz who created the term "Butterfly Effect"

http://www.ganssle.com/articles/achaos.htm

Nobody has mentioned Jack Ganssle or Embedded Systems Magazine? Visit http://www.ganssle.com/, subscribe to The Embedded Muse, and if possible go to one of his Seminars.

I'm lucky, I started as an electronic tech in the late 70's. I learned to write software to wiggle wires for troubleshooting, engineering found out about it and drafted me. Went to school for my degree (math), and haven't had much trouble working since.

Here are some suggestions to becoming a proficient software engineer:

1. Learn to work your way up the capability maturity model (and help your company to do so). See item 6 in the following article.

Learn to avoid the "7 Habits of Highly Dysfunctional Developers". http://www.ganssle.com/articles/7habits.htm

2. Jack Ganssle's articles are great reading for programmers wanting to build reliable systems. They are helpful for both embedded programmers and people working on other platforms.

http://www.ganssle.com/articles.htm

3. Here is Jack's recommended reading list.

http://www.ganssle.com/bkreviews.htm

I have found his own books to be useful.

http://www.ganssle.com/book.htm

4. Jack's articles in Embedded Systems Programming magazine contain lots of programming wisdom.

http://www.eetimes.com/electronics-blogs/21/Break-Points?Ecosystem=embedded

Here are some suggestions to becoming a proficient software engineer:

1. Learn to work your way up the capability maturity model (and help your company to do so). See item 6 in the following article.

Learn to avoid the "7 Habits of Highly Dysfunctional Developers". http://www.ganssle.com/articles/7habits.htm

2. Jack Ganssle's articles are great reading for programmers wanting to build reliable systems. They are helpful for both embedded programmers and people working on other platforms.

http://www.ganssle.com/articles.htm

3. Here is Jack's recommended reading list.

http://www.ganssle.com/bkreviews.htm

I have found his own books to be useful.

http://www.ganssle.com/book.htm

4. Jack's articles in Embedded Systems Programming magazine contain lots of programming wisdom.

http://www.eetimes.com/electronics-blogs/21/Break-Points?Ecosystem=embedded

Here are some suggestions to becoming a proficient software engineer:

1. Learn to work your way up the capability maturity model (and help your company to do so). See item 6 in the following article.

Learn to avoid the "7 Habits of Highly Dysfunctional Developers". http://www.ganssle.com/articles/7habits.htm

2. Jack Ganssle's articles are great reading for programmers wanting to build reliable systems. They are helpful for both embedded programmers and people working on other platforms.

http://www.ganssle.com/articles.htm

3. Here is Jack's recommended reading list.

http://www.ganssle.com/bkreviews.htm

I have found his own books to be useful.

http://www.ganssle.com/book.htm

4. Jack's articles in Embedded Systems Programming magazine contain lots of programming wisdom.

http://www.eetimes.com/electronics-blogs/21/Break-Points?Ecosystem=embedded

Here are some suggestions to becoming a proficient software engineer:

1. Learn to work your way up the capability maturity model (and help your company to do so). See item 6 in the following article.

Learn to avoid the "7 Habits of Highly Dysfunctional Developers". http://www.ganssle.com/articles/7habits.htm

2. Jack Ganssle's articles are great reading for programmers wanting to build reliable systems. They are helpful for both embedded programmers and people working on other platforms.

http://www.ganssle.com/articles.htm

3. Here is Jack's recommended reading list.

http://www.ganssle.com/bkreviews.htm

I have found his own books to be useful.

http://www.ganssle.com/book.htm

4. Jack's articles in Embedded Systems Programming magazine contain lots of programming wisdom.

http://www.eetimes.com/electronics-blogs/21/Break-Points?Ecosystem=embedded

memory read speed on the current Devkits is something like 3 orders of magnitude slower than the write speed

I agree that for a non-mission critical type of software, bugs are acceptable. As long as there are workarounds (e.g. avoid doing things that cause the bug to occur), it would be ok.

However, for mission critical software such as medical devices that deals with raditions output or heck even slot machines, bugs are unacceptable.

A good example is the Therac 25 where due to bugs, it actually injured people. http://www.ganssle.com/articles/disaster.htm

I hope the poster of this article or anyone who is in group 1 will never work on any mission critical software.

If they're really that bad (and I CAN believe it) AND you have management support, you have a few options. For Test servers, set them up in your own department on a private lan. Do what you want with them.

Talk with some of the actual techs in IT. Find out what the problem is. It could be truly miserable managers in their department, it could be upper management pressure on IT leading to the ultimate in CYA, perhaps a CIO with a tinfoil hat collection. They might be seriously understaffed and use the paperwork as a way to eliminate frivolous requests.

Or they could just be ID10Ts.

If none of that works, resign yourself to resigning. But before you do, order 100 Signetics 25120s. Be sure to fill out the paperwork in exacting detail. If they can't seem to find them, print the datasheet for them (page 2). Insist that any other part will allow Chinese companies to sniff all your data.

Then resign, QUICKLY

If they're really that bad (and I CAN believe it) AND you have management support, you have a few options. For Test servers, set them up in your own department on a private lan. Do what you want with them.

Talk with some of the actual techs in IT. Find out what the problem is. It could be truly miserable managers in their department, it could be upper management pressure on IT leading to the ultimate in CYA, perhaps a CIO with a tinfoil hat collection. They might be seriously understaffed and use the paperwork as a way to eliminate frivolous requests.

Or they could just be ID10Ts.

If none of that works, resign yourself to resigning. But before you do, order 100 Signetics 25120s. Be sure to fill out the paperwork in exacting detail. If they can't seem to find them, print the datasheet for them (page 2). Insist that any other part will allow Chinese companies to sniff all your data.

Then resign, QUICKLY

Yes but flash will overtake hard drives in most Write-Only Memory applications.

When I first started with my current company over 3 years ago, I was asked to put together a coding standard. I started with:
http://www.ganssle.com/fsm.htm
If doing embedded/firmware it's a great start; though it's a great start for any code work.

Here's my opinions:
1. Good comments are valuable. Comments that tell you why something was done the way it was are invaluable.

2. Use a code repository. CVS is what we use. And use the thing, check-in frequently.

3. Backups. 'nuf said.

4. Don't worry about specific code style issues (especially brackets). Just make a requirement that people follow the style already in a project (or file if you want to get that granular) as they add and modify. Be flexable, there's really much more importaint issues (like vi vs. emacs).

5. make and other automated ways are your friends. Automate as much as possible; it's too easy to forget that one silly commandline incantation you have to do to build the major product and end up having to re-release to fix something.

6. Templates. Have a project in CVS of standardized file templates. Make one for each file type you've got: header_c_template.h, header_cpp_template.h, module_c_template.c, module_template.cpp, Makefile_template, etc...

Saves time and avoids unnecessary rework. Also, new people to your organization will know what you expect in your files.

Jack Ganssle is widely respected in the Embedded Development world, and has an excellent Coding Standards manual on his website (it's an MSWord doc). While it's geared specifically to coding for embedded systems, much of what is in there applies to coding in general.

Less of a specific approach and more of a "this guy can help you learn about your options" is Jack Ganssle (website: http://www.ganssle.com/ )

He focuses on firmware, so its not highlevel application stuff, but if your lowlevel his insight and suggestions are pretty useful. The core of his work is presented in lectures he gives, both publicly and privately for specific companies.

He also writes monthly for Embedded Programming, normally something funny but with a serious point. And to cap it all, he's a pretty nice guy.

Check it out, see what you think. He helped me improve my coding and my team quite a bit.

> Microwires Can Replace The DVD-ROM [...]
> Anyway, it's not that easy. Researchers say that the greatest difficulty will be with the reading of information.

If reading the information was impossible, this could be a great alternative to the DVD-WOM

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

It's not.

There are bugs that affects applications to a level the user notices, and there are bugs that affect the maintainability of the code, the reusability of the code, and the ease of use of the code. Most bugs are hidden from the user's view.

Does a stack overflow in a piece of code that only occurs when a craftily created exploit is executed constitute a bug? Yes it does -- even when no exploit exists. Under normal operations it does not affect the use of the system -- at least not until an exploit is developed and widely used. The fact that Windows, especially the older versions of the OS, were vulnerable to so many simple exploits illustrates the bugginess of the code. And most of the bugs are not even in close enough to the surface to be so readily exploited.

Does an end user see API bugs? Does anyone outside of Microsoft experience architectural flaws in the Windows OS? No, but that does not mean they do not exist.

What about code that misbehaves when presented with certain data. That may not be a problem for the original application that the code was written for, but any time that code gets reused, the programmer must know about these "hidden features" (read: bugs). Again, the user never sees this sort of bug.

The number they came up with wasn't pulled out their ass. See this article on measuring bugs for a more detailed discussion on the topic.

When reading it, bear in mind that most commercial software is produced for in-house use, receives very little QC, and frequently does not even compile cleanly. It's usuall just "good enough" to get the job done.

Check out Jack Ganssle's site

particularly:
Articles such as I, Consultant

There are 5 parts to that article.

--buddy

While people may seem to think that Write Only is a silly idea, here is a datasheet (front, back) with the specifications for some WOM from Signetics.

I really do with they would have promoted this more. It seems like a quantum leap forward in computing!

While people may seem to think that Write Only is a silly idea, here is a datasheet (front, back) with the specifications for some WOM from Signetics.

I really do with they would have promoted this more. It seems like a quantum leap forward in computing!

1. The kneejerk answer is the same one that was kicking around when I was in college in the 80's: efficiency. Obviously, anything you would even contemplate coding in assembly due to speed concerns should not use any unnecesary overhead. In fact, in highly optimized code even procedural programming is a mistake (although those situations are even rarer). As to how one would code OO in assembly, see below...
2. Inavailabity of tools: I have seen many embedded projects that use legacy compilers that do not support OO or have very poor OO support (i.e. pre ANSI C++). Often the tools can't be upgraded because they are no longer supported or it's just not in the budget. Under those circustances, some developers are tempted to kludge an OO looking design on top of a procedural structure - lots of function pointers hanging everywhere to simulate class methods, fields in structures identifying types to support run time polymorphism - all the things the compiler is supposed to do for you. You wind up with a design that's more complex, not less, because you have to implement the OO underpinnings as well as what you're trying to do in the first place.

   There are, naturally, exceptions. UNIX pioneered drivers in C with general purpose routines referenced via pointers - basically a base class (stream or block driver) with subclasses having device specific code embedded in class methods. Taking it much further than that would be a horrible mess, though.

3. Finally, the biggest mistake in implementing an OO solution (IMHO) is when there is little reuse of components (aka: forcing an OO solution on a non-OO problem). I worked with an OO advocate who pushed a scheme of representing our entire system as objects: a status light would invoke a message method in a dumb router box which would invoke a method in our method in our platform to build the core message, wrap onion-esqe headers around a message structure and then shove the structure down into a driver. While it was really cool to be able to put "box1.router2.statuslight[22].blink();" in your code, the fact was that none of the boxes had anything in common. Every one had a different structure for messages and different timeout issues. As a result, nothing inherited from anything and none of the code ever got reused within the platform. Worse, there were no upgrade efforts on other platforms, so the stuff wouldn't get reused there either. Basically, the whole thing was just a bunch of procedures hanging off an object framework - we never got any advantages of OO but we still got all the headaches of implementing an OO design (i.e. objects all over the place, many of which were just shells to allow others to be invoked in certain ways and didn't contribute to functionality).

   Jack Ganssle had a great metric in one of his seminars: Reuse of code is not cost effective until it has been used five times. You often see developers trying to do the right thing and make reusable libraries, etc. only to see the effort abandoned around the third iteration. That's because coding for the general case is often tough and requires a lot of testing that you'd never do if you were just coding up for a single project (ask anyone who's coded a driver or library that stays in house for use on a few projects and one that actually goes out to customers as a COTS solution). I believe OO is a lot like that: If it's a design you're going to conceievably be reusing five times, code that puppy as objects to give you a nice, clean interface. Otherwise, don't try it unless your design lends itself strongly to objects that can be reused within the scope of your current project.

   In the words of Dennis Miller, though, I could be wrong...

The router that implements this evil bit could send the packets to Write-Only-Memory.

"In 1972 Signetics recognized April Fools day by printing a full color datasheet for a Write-Only Memory. This is a chip which accepts data but never reads it back. Suggested uses include a data logger for bombs. Graphs show "number of pins left versus number of insertions" and other useful data. A couple of pins are dedicated to 6.3 volt AC input... for the filaments, of course! A scanned version is here (page 1) and here (page 2) (these are 150k .JPGs)."

The router that implements this evil bit could send the packets to Write-Only-Memory.

"In 1972 Signetics recognized April Fools day by printing a full color datasheet for a Write-Only Memory. This is a chip which accepts data but never reads it back. Suggested uses include a data logger for bombs. Graphs show "number of pins left versus number of insertions" and other useful data. A couple of pins are dedicated to 6.3 volt AC input... for the filaments, of course! A scanned version is here (page 1) and here (page 2) (these are 150k .JPGs)."

The router that implements this evil bit could send the packets to Write-Only-Memory.

"In 1972 Signetics recognized April Fools day by printing a full color datasheet for a Write-Only Memory. This is a chip which accepts data but never reads it back. Suggested uses include a data logger for bombs. Graphs show "number of pins left versus number of insertions" and other useful data. A couple of pins are dedicated to 6.3 volt AC input... for the filaments, of course! A scanned version is here (page 1) and here (page 2) (these are 150k .JPGs)."

Well, it wasn't awfully funny, because I forgot to preview to make sure I typed in the link.

Here's the second page of that patented invention.

Well, it wasn't awfully funny, because I forgot to preview to make sure I typed in the link.

Here's the second page of that patented invention.

A sail boat is quite a different environment from a power-driven ship. Jack Ganssle is an engineer and programmer with a serious sailing hobby, and he tells all sorts of stories of saiboat autopilots failing due to saltwater corrosion. I remember but cannot fine one article concerning long a single-handed race, where he had several spare autopilots and all of them failed. Since he was alone, the autopilot was critical. He kept repairing them, but his big question was, how would anyone who wasn't an electronic engineer or tech cope?

And these things are built for saltwater, unlike off-the-shelf computers. OTOH, the autopilot would be on deck next to the tiller, so exposed to saltwater spray pretty much 24x7. The cabin would be a little more protected - there might be condensation dripping from the ceiling, but it shouldn't be salty... Still, if it's mission critical (like how you get your weather reports), it's going to be hard keeping that computer going.

"On Cryptographically Secure Write-Once, Read-Never Memory And Its Application To Buzzword-Compliant Technologies."

Hmm, in other worse, a crytpographically secure version of this?

So, they had overclockers back in 1972? Nothing new under the sun, I guess...

I think you're talking about the fabled Signetics 25120 fully encoded, 9046 x N, Random Access, write-only-memory, released in 1974. Here are page 1 and page 2 of the data sheets.

I think you're talking about the fabled Signetics 25120 fully encoded, 9046 x N, Random Access, write-only-memory, released in 1974. Here are page 1 and page 2 of the data sheets.

[S]earching on Alta Vista ... gets me over 80 hits, the last 40 of which have NOTHING to do with my search at all....

How did the first 40 hits do? How about the first 10? I ran that search on google and the first hit was to the jargon file entry and the next few were all about ... well, they were about Signetics write-only memory. The sixth result had jpegs of the original data sheets.

When the search turns up good results, who cares if there are some bad results far down the list?

Writing code for these devices is a complete art form in itself - every processor cycle and every byte of ROM and RAM count. Your can get C (and even Basic) compilers for these devices, but you have to use assembly to squeeze out the last drop, and do some very dodgy tricks to use all those spare bits hanging around. We don't use OOP for obvious reasons ;-)

I spend most of my time writing embedded code, every once in the while I code for PC end (64Mb RAM, 1GHz clock wow!), and it is so relaxing not having to think about every byte and the most efficient way to code loops etc, but it makes you think that there must be a hell of a lot of wasted clock cycles in most applications because there is no pressure to tighten the code.

Check out The Ganssle Group for some great articles on embedded development.