Re: Towards better embedded software (long)(was: Re: Where does C++ fit in?)

I am one of the people who cleaned up others people mess for Y2K! For a very big company over here...so that mess was good software for me (at least for my bankaccount).

All my software has been tested and approved! I never ever used 2 digits, the idea alone.

There always have been good and bad programmers. The first software I even had to work on (still as a student) was a TurboPascal 3.x application: I will never forget that. Really learnt me how NOT to do it. It has 37 procedures. The people who programmed it probably did not know how to use parameters. And all data was global. All variables were abbreviated. There was no documentation (they told me they were afraid the competition might get a copy of it). All procedure were called Proc1 to Proc37 (yes. there were 37 procedures). Horrible. It even did RS232 communication. I had to 'spy' the rs232 communication to find out how the protocol worked. Took me months to build they same software as it should heva been in the first place.

So indeed generalisations are not good. I still see good people. But I also see a lot of people just gluing things together, trying 'does it work' and then it ok to them. I for example always check ALL boundarys (calculating algorithmes tested for highest and lowest input, and 0 on critical points, check array pointers twice etc.).

Pieter

CMM is the latest way to go. It does not describe how to build the software, but how the process building performs. How people work together, make documents, reviews etc.

Pieter Hoeben

It depends how much of the project is in your line of sight.

Code reviews and proper documentation, not to speak of consistent variable & parameter naming and other good design stuff all take more time to do. It's the "we'll worry about the problems when they surface" attitude that leads to the delay that you describe.

--

"Jokes mentioning ducks were considered particularly funny." - cnn.com

Jim Granville wrote: [...]

Take it / send it back. Make sure it's soiled enough that the retailer cannot just re-box it and restock it. This is the only way to fight this crap - do not put up with it.

You would expect oven firmware to be in the category of 'been around since '86 with _minor_ changes per model. Guess not.

[...]

My point exactly.

I would only add that we as a culture should demand and expect this to be the norm, as in other disciplines.

Steve

Construction industry. Contracts routinely have what the contractors call the "murder clause" which says it's the contractor's responsibility to correct any design errors or omissions at no additional cost to owner.

Having done maintenance programming for a long time, I can assure you that having good debugging skills is A Good Thing.

Personally, I would be far more suspicious of anyone who told me that his code never needed debugging.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

You're preaching to the choir. I doubt there is anyone in this NG who has had the exquisite luxury of trying things "both ways" who would disagree with you. On average, it will take less time to reach a given quality point if you plan and execute the plan properly.

But it is an EXTREMELY difficult problem to convince people of this, because it's counter-intuitive. Also, during the planning phase there is apparently little concrete progress, which makes upper echelons antsy. Funny how these people can justify their entire existence through a stream of PowerPoint bullshit read by nobody, but once engineers start measuring their productivity in hours of discussion and pages of (text) plans, things are different...

I'm on your side here folks. Unfortunately a lot of people, particularly at a senior level, aren't aware of the above, and when the project is being squeezed by time pressures these things can suffer.

What I was responding to was the notion that implementing these design measures was a simple matter of convincing people that it was the right way to proceed.

--

"Jokes mentioning ducks were considered particularly funny." - cnn.com

My first post-college job was as part of an I.T" group. Part of my job was maintaining system admin tools. A set of these were really horrible Pascal programs. After laughing at one particularly bad segment of code, one of the managers said "yep, Dave really loved Pascal, too bad he didn't know how to program in it".

--
Darin Johnson
    My shoes are too tight, and I have forgotten how to dance -- Babylon 5

It is amazing how many projects small and large get forced to timescales as "managers" expect a time scale without even the faintest outline spec or outline design, from before the project starts.

Then politics come into play.... :-^

--
Paul Carpenter		| paul@pcserv.demon.co.uk
        Main Site
              GNU H8 & mailing list info.
             For those web sites you hate.

Kinda agree with you -- I wouldn't markdown anyone who said they were good at debugging. However in my mind, debugging is not the approach one uses to discover bugs, but a method to fix known bugs. I'd be particularly interested in their testing strategies as this relates to one's ability to make statements on how "bug-free" their software is.

Yes, I consider bugs to have a wide scope and not just coding errors. After all, a piece of software could be beautifully crafted but fail performance criteria.

There are (generally) 2 types of bugs which are present in commercially available software:

1. Unmitigated known bugs. These bugs have been fully assessed as to their impact to the end user. Due to commercial constraints they are permitted to exist in the final product.
2. Unknown bugs. These bugs are undiscovered as their detection was not covered in the testing strategy. They are revealled via some unusual or unspecified use case.

Ken.

+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com

Hmm. Depends (again) on your definition of debugging.

If you mean aggressively testing (and setting traps and sentinels) for logic and coding errors during development, then I debug. If I screw up, and I do, I want to know about it as soon as possible.

If you mean having to hunt around for things that have gone unexpectedly wrong at a late stage in the development cycle, I don't debug. I really, really *hate* that kind of debugging, so I plan to avoid it. I usually succeed.

We've had this discussion before - last time I said this, I got jumped on by those who said it's not possible, I must have only worked on simple systems, etc etc. How about a piece of software that monitors for several thousand events, monitors several hundred known sequences, compares these to "safe" conditions, and sequences another several thousand potential responses, all in realtime with no *possibility* of any kind of overflow or indeterminate state - is that simple? Or a system with upto 66 (don't ask - legacy) inter-communicating CPUs - is that simple? Well, yeah, actually, they *are* simple - because I broke them down into simple synchronous chunks. I sometimes think I cheat ;).

I *so* hate the commonly held belief that complex software has to have bugs. (With apologies, again, for those who have heard this rant from me before... once or twice...)

Steve

I totally agree. I've seen it happen.

Many years ago, two guys started two similar projects at the same time. One guy had a rough prototype up and running in no time. The other guy, meanwhile, sat down at his desk and stayed there for a number of months making no such spectacular initial progress.

The first guy's prototype grew more and more code over the months, and he was still debugging and trying to tame his monster when he ran out of time. It worked, but a few unpleasant surprises crept out of the woodwork over the next few months and years.

Meanwhile, the second guy had built a model effectively on paper, which he then refined into an increasingly detailed formal functional definition. He then spent a few weeks coding and verifying the definition, until one day he switched it on and it all just worked. No surprises. It was almost boring.

Guess which project came in on time, had no bugs, and had the better market acceptance.

Guess which guy was me ;).

Steve

It amazed me how often managers would slash complete phases from a project like, design review, prototype review, or testing in an effort to save time and money. And I was also amazed by how often managers saw hiring an inexperienced programmer at a lower rate as a way to save money on a project. Often these sorts of project management decisions come down from the manager above the manager who knows that there are better ways.

Best Wishes

Giveaway of what exactly?

I am quite good at debugging, and in a PPOE I was the guy people would come to when they had an bug their own guys couldn't fix. Often they were heisenbugs or intermittents of one sort or another.

I always found the problem, though sometimes it was a battle. I don't think this is anything to be ashamed of.

--
Burn the land and boil the sea,
 You can't take the sky from me.

It is a difficult thing to be *certain* that complex software doesn't have bugs.

--
Burn the land and boil the sea,
 You can't take the sky from me.

Again, I disagree. I believe one can, and should, plan to be certain.

Steve

Absolutely.

There is, of course, a difference between being good at finding bugs, which you are, and having to fix your own bugs all the time, so you get good at using a debugger. I think it's *those* types that Mr. Fenelon was talking about. Those types typically characterize themselves as being "good at debugging"; those of you who really are good at debugging would surely describe them somewhat differently.

--
Daniel Kelley - San Jose, CA
For email, replace the first dot in the domain with an at.