As opposed to your locality, where the cows clearly have a regrettable tendency to overacting. Either that or the pigs have been genetically engineered to produce beef-flavoured bacon.
I arise in the morning torn between a desire to improve (or save) the wor= ld and=20 a desire to enjoy (or savor) the world. This makes it hard to plan the da= y. =97E. B. White
The Microsoft mantra, that all software has bugs, is an excellent mind-set for making bugs. If one assumes that bugs are undesirable and in fact a disgrace, coding can be designed to minimize errors first pass. I do that, because I like to lie in bed and nibble chocolate and review my code, and I hate to sweat over emulators and stuff in the lab. More important, if you depend on testing to find bugs, you'll never find all of them.
Now here's a guy with a work ethic I can understand! I even think what yo= u have=20 to say has the ring of profundity: if one has so many bugs that one can't= fix=20 them through simple insight into the code, they have already infiltrated = the=20 product to such a degree that you can no longer cure them. You can only r= inse=20 them, a process that removes a more or less constant ratio of them (and l= eaves a=20 ratio of them). I've worked on more than a few such projects. Once this h= appens=20 you can forget about getting the code squeaky clean.
I like the bit about troubleshooting while nibbling chocolate in bed, too= !
--=20 Dwain Wilder Bear Meadow Folk Instruments
formatting link
I arise in the morning torn between a desire to improve (or save) the wor= ld and=20 a desire to enjoy (or savor) the world. This makes it hard to plan the da= y. =97E. B. White
I'm curious (honestly). Other than your mindset, what do you do differently than the "hack-and-debug" majority. John suggested thorough code reviews. Anything else?
Do you actually test your software? If so do you find bugs during testing?
Is it your experience that hardware designs are normally right the first time?
How complex are your software designs relative to your hardware designs?
It's interesting to compare. If I design a PC board full of parts, and anything's wrong, I have to write an ECO to manufacturing to kluge the board, and that's a very public admission of error. If it's too serious or ugly to kluge, we have to roll the PCB rev - lots of work - re-release the drawings, wait for new boards, build the next iteration, etc. Again, very public and very expensive. So most hardware works the first time, because the economic and social pressures punish sloppy work.
Software, on the other hand, can be patched forever without traces peeling off, and the entire process is pretty much done in private. So software, even short routines, are seldom right the first, or even the second, time. Interestingly, FPGA designs often tend to be like software, sloppy and buggy on the first pass, at least by some people. Anybody who designed a hard ASIC this way would be unemployed pronto.
Debugging just tells you about where in your code to look for blunders, at which time you read the code, smack yourself in the head, say "of course", and fix it. So why not do that *before* you test the code?
Interesting. I've worked in both the hardware and software camps, and at most of the software jobs we had even more elaborate release procedures for software than for hardware. ECOs required in both cases, but the hardware release process didn't usually include releasing modified test plans and test reports, as well as updated design documents (use cases, specs, whatnot, marketing and sales signoffs, etc). Of course, I've worked in software environments where whatever we installed on the master server was what the customer got, and there wasn't even any source code control system - just nightly backups of the server.
After trying it a variety of ways, I prefer a strong ECO process with the QA-maintained document control library for released documents, and both user-level (ie, just for me and my private use) and group-level (ie, for everyone on the team) source code control systems. But when it comes down to it, I'll do whatever the customer wants. If he doesn't care, then I do it my way ;)
It all depends how you work and how your project runs. If your specifications are rigid, you can do a lot of analysis and design checking up front and save debug time in the long term. If your project is a never-ending series of "we like this but not that and can it also do this other thing?" it gets harder to maintain design discipline nd analysis. I'm a big fan of writing self-tests and test stubs in all of my classes now so that by the time I start integrating things I've already got a high level of confidence that my components actually work. "Baby Steps" is my work mantra.
"Mindset" is probably the key thing. Other elements include: - Planning: I design before I code. - Defensive design: I use a variety of techniques to ensure robustness, and insensitivity (and hyper-sensitivity) to change. - Synchronism: I use all the same techniques I learned doing ASIC design to ensure synchronism i.e. positive data handover. - Maintainability & readability: if I can't read the code at a glance, I consider it broken.
testing?
Of course ;). But the bugs I find tend to be glaring and easy to find. I almost never introduce, or indeed need to find, subtle bugs. I emphasise that my testing tends to be code verification, rather than active debugging.
Mine tend to be - I've had right-first-time design drummed into me, and with hard ASIC design, you tend not to get a second chance. This presupposes that the spec was correct, of course ;).
I get asked this a lot, and I understand why - but my response is always the same: I break complex things down until they're a collection of simple no-brainers ;). An example: I did a revision of a rack-based product involving up to 70-odd intercommunicating processors, in 4 classes, designed in C and hand-compiled in assembler - with no debug tools at all. All I could do was turn the system on and see if it worked. Apart from one typo which positively yelled at me, it did indeed work first time. The product has since been extensively field-tested (the '98 World Cup TV coverage depended in part on it working correctly); no bugs were reported or have surfaced since.
Complexity isn't the issue. I've seen poorly-designed 2-page programs. Perhaps the most constructive thing one could do to ensure bugfree design is to take the debug tools away ;).
So what's special about me? Nothing. I just hate debugging. As another poster said, there will always be bugs that debugging won't find *unless they're designed out*.
I agree completely. One further point: I can plan (i.e. allow time) for verification; but I can't plan for debugging. Therefore I prefer the former ;).
I've done both ;). Also, as a consultant, I guarantee my work - if any bugs do show up, I will fix them - whatever it takes - at no cost to the customer.
I *much* prefer the formal approach - deliverable/demonstrable test harnesses that get maintained along with the code, and a structured bottom-up code walkthrough. However, I've had to learn to "wing it" sometimes - see my earlier post re software testing with no debug equipment. As a consequence, and as a survival strategy, I've wound up making my code as clean and as clear as I can from the start, and actively avoiding bugs while coding. I don't actually recommend this no-safety-net approach - but sometimes I've had to perform the impossible in ridiculously short timeframes knowing that I wouldn't get a second chance.
Clarity and maintainability are now probably my two most important buzzwords. They're the same thing, really.
Most ICs seem to take at least a couple of expensive tries to get right and many take more than that. It may vary between ASICs and full custom designs.
Ever considered how to apply a software patch to a few million TVs? Once it really goes out you are not going to patch it unless it is something very serious.
-- Stephen Baynes CEng MBCS DTG-S&S, Philips Semiconductors Southampton Tel +44 23 80316431
I'll agree with the above, but there is another factor at work here. In most cases, hardware engineers have a better understanding of the overall system requirements. This also extends to those of us who do embedded s/w development, where there is very tight coupling between the s/w development and the overall product development.
I've worked in everything from the embedded world to business systems s/w. The most significant factor affecting the success (or failure) of the software is whether those that do the analysis, design and testing understand the domain for which they are developing.
Tools and formal practices are good, but they will fail to produce a quality product if the developers don't understand the problem to be solved. Unfortunately, there is a trend in some industries to separate system, hardware and software development, sometimes separated by many time zones.
--
Paul Hovnanian mailto:Paul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
Aleph-null bottles of beer on the wall
Aleph-null bottles of beer,
You take one down
and pass it around
Aleph-null bottles of beer on the wall
This is validation -- that is checking whether the proposed solution is appropriate. There are analysis tools available that help the engineer address this, but I think you're correct in asserting that this is a poorly travelled area.
Business is driven by economics and the Capitalism of the Western World calls for businesses to seek a competitive edge. That's why US companies employ Indian programmers or have their goods manufactured in China. Typically a business must view itself as global rather than provincial, because an outside company could come in and quickly acquire a reasonable market share. Obviously to capitalise on global resources & skills, a company needs to acquire the organisational skills, but it can be done and in fact (as you have pointed out) many companies are doing it.
I actually see the separation of hardware & software development as a good thing, mainly because systems are becoming so complex that finding people who have the right skillset in both hardware & software is becoming very difficult. Also "software" today is no longer about "cutting code" which only really consumes about 5% to 10% of engineering effort. It's about producing a deliverable that will make the customer happy. So most of the effort goes into analysis, design and testing. To do this properly you basically need a trained Software Engineer rather than a hardware engineer who's a weekend programmer ;-)
Ken.
+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com
Trouble is those that just sit and hack at code tend to introduce nearly as many new bugs as they are eliminating old ones. Never mind that once you have written and released buggy code you will probably never rid yourself of it.
A well thought out system design will have eliminated 99% of all the bugs in specification and design before you have even laid one line of production code. It should also, despite complexity of the problem, be simple enough to understand fully. This will assist in elimination of the final 1% of bugs during the integration testing. Factory testing and Commissioning testing can then be "REALLY" proving to the customer that you have completed a system to his requirements.
I for one do not consider hiring "software only types". I always go for those who have an aptitude in hardware topics as well (whether electrical, mechanical or electronic). Note that on team projects you have to have some balance in the team and the team must be able to understand each others work in order to peer review it.
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Yes. Very thorough review of the original requirements specification and contract details in the first place. Until the original specification is as right as it can be it is pointless designing any part of the system. From that point it is just a matter of factoring the design so that you end up with a clearly defined functional modularity and thus removing the apparent complexity of system by improving your understanding.
Absolutely yes. Probably more than most. Each individual routine is tested as soon as it is written (one of the beautiful things about working with Forth is the lack of need for coding test stubs). That way if the code does not fulfil the criteria of the requirements it is easily modified, retested and improved before it is submitted for inclusion in the intergated product (Edit Code->Compile->Test->Edit Code->Compile->Test.......).
Mostly yes. Usually when the design problems have been very thoroughly understood and the solution becomes very apparent. It is usually better to think a little longer rather than go through making several versions of the PCB or chip (costs too much money that way).
Mine range from equal to the software doing very highly complex things. However, I never feel that my software is, itself, highly complex.
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.