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

I've thought about this quite a lot, and I think such poor standards adherence and quality control is to do with the simple fact that you can get away with it. Someone else has to worry about the costs later.

As someone else has said (in a different way) cutting the odd corner here and there puts you ahead of your competitor. If your competitor is already doing it, you'll have to cut corners to compete, or face a different range of risks.

Yes, this is the usual justification. My experience, however, is that cutting corners doesn't actually save time. It's a flakey premise. I'm challenging this idea out of pragmatism [1] and practicality, not idealism.

Steve

I disagree... This is the usual _management_ justification. The usual _engineering_ justification is that management forces engineers to develop products using arbitrary techniques du jour, or with unrealistic timelines, or some other silliness. And there are no rewards for a job well done, only for a job done on time.

This is merely another demonstration that behavior that is unrewarded will not be repeated.

snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards) wrote in news: snipped-for-privacy@posting.google.com:

I agree, in my experience even with concrete evidence that time invested up front reduces overall project times and overall costs, non-software managers will still ask "Well ok, but how much time can we save if we don't have the detailed design phase?".

This happened to me immediately after I lead the software development for a project that for the first time in the company's history had the software finished before the target delivery date, and which had just one non-critical bug - introduced when the hardware engineers required a change days before going to mask.

Investment in planning to get it right first time does pay off, but its an extremely hard concept to sell, both to technology directors and to software engineers champing at the bit to start coding.

Peter.

Amen to that.

Steve

We all know already that corner-cutting doesn't save time in the long run. But yet, we are told to do it anyway. *shrug*

I disagree. Let me be blunt: it's s/w engineers I'm getting at, not managers. It's the engineers who need convincing, if only so that they can convince their managers - the same way mechanical and electronics hardware engineers have done for decades.

No, it's down to us. You can't blame bugs on managers.

Steve

Is it generally your experience that this is possible ? I'd love to live in a world where getting things done the right, but slower way was simply a matter of convincing the manager to go down that route.

You make it sound like a manager vs engineers issue. Getting the bugs out of the software is team work.

OTOH efficiency measures do save time. We don't call it corner-cutting until we've found out it didn't work.

Regards. Mel.

Aha! Caught you. The myth of "the right, but slower way" is *exactly* what I'm challenging. Doing things right takes less time. And yes, this has been my experience. Build the foundations right, and the house won't fall down when you get to the third storey ;).

Steve

Re managers vs engineers: not my intention. I'm a project manager as often as I'm a coder. As a manager, I'm dependent on my engineers for realistic time estimates for their parts of the project (and I'd better be sure I've done a good job of parcelling them out).

Re getting bugs out as team work: I'm all for team work, sure. But (as I've said many times here) I don't believe in debugging, period. I *do* believe in not having bugs in the first place. That's down to a certain attitude; managers play a large part in fostering and encouraging this attitude, but engineers are the ones who embody it.

Many (too many) engineers - and managers - don't believe this is possible in practice. It's noticeable to me that the best engineers I've worked with

Steve

'bugs' is a very widespread term, and means different things to different people. Quite often, errors in design do not appear when the SW-coder does the testing : They are testing what it SHOULD do, and also travelling along known state-paths.

I have seen many problems surface where what it should NOT do became very important.

Quite often, the spec simply assumes some of that knowledge, and if someting fails do to operator miss-use, do you call that a bug, or a 'variance in specification'

- and does the end user care WHAT it is called ! :)

As a real example, my sister has a new oven, and the clock is a good example of poor SW state engine design. ( well, I actually HOPE it's faulty, as it's embarassing to see just how flakey this is )

You'll know the type of thing : A 24 Hr clock, and a handfull of buttons : TimerMode CookTime StopTime ManualMode +/- buttons.

Timermode did work for maybe half a dozen tries, for the first half hour, then it went '100% out to lunch'. The button itself is OK, as that's needed to set the clock. Manual mode _mostly_ overrides what is happening, and sets to manual ( but not always )

-ve button has some 'extra feature', and in some modes, will trigger CookTimer After a AutoCycle the BEEP halt works 100%, but the return to manual mode works very rarely. Mostly, starting a Mode gives you a 4 second display-grab window, in which to start +/- defines. But not always....

The only mode that seems to be consistent is SET TIME, and maybe that's considered a Spec Pass ?! :)

Power-off and on, with reasonable OFF times makes little difference, tho I suspect a really-long off time might help..

I've asked the manufacturer if this is known behaviour, but I'm not holding my breath.

I did find this on the web:

which is a pleasing sign that some CS courses talk about specs....

-jg

I always grew suspicious when I saw CVs where people said they were good at debugging. If they got as far as interview (few did) there was always one fairly obvious question ;)

pete

I wrote a web page that discusses this very subject:

Yes, bit of a giveaway, innit? ;)

Steve

been

from which I quote:

Pete Fenelon wrote in news: snipped-for-privacy@fenelon.com:

Well I don't know... my attitude is "all software is guilty until proven innocent" - also known as debugging by bloody-mindedness. There again, if I've eliminated errors before releasing code, couldn't I say there were no bugs and therefore I hadn't been debugging? I wouldn't mind too much if someone said he was good at debugging, if it meant he actively looked for problems in his own or other people's code, rather than glazing over and saying "looks ok to me".

One problem is that we call them "bugs" - makes them sound cute and whimsical. They are MISTAKES caused by failing to think through the problem, and the longer they go undetected the more expensive they are to fix.

Point taken, but I talk in terms of "good design" and "verification" rather than "debugging" ;).

Exactly. I can't think of any design activity that I'm involved in where failure is accepted so casually and routinely - other than software.

Steve