Dilbert strip

This only works if there are no hardware dependencies/interactions in the toolset. E.g., a piece of development kit that expects a PCI bus

*needs* a PCI bus in the host supporting the VM. Ditto with other hardware interfaces (serial/parallel ports, etc.) [Hysterically, hardware interfaces have become obsolete leaving certain tools as orphans. And, older tools often used legacy interfaces in ways that weren't inherently portable. E.g., a USB "serial port" may not behave as a "real" serial port is expected to behave for some piece of software trying to talk to that interface. I.e., long support timescales can have other issues that eat your lunch, unexpectedly. Anyone have a HARD SECTORED *8* inch floppy drive lying around? :> ]

Changing all variables to be single letters and then letter pairs was one that we used. But not just for obfuscation but to allow slightly larger codebases to be crammed into extremely tight interpretted systems on delivery (back when ram memory was expensive and scarce).

--
Regards, 
Martin Brown

That's still done for JavaScript, so as to minimise comms costs and latencies.

Hilarious!

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

At least they didn't compile to assembly, and then import that :)

Michael

Write a system architectural document, and a circuit description. Make the software people write at least high-level design documents, or put block-diagram level documents in your architectural document. Do the same with the HDL folk.

The ONLY time that I've been able to make this work 100% was when I had a cooperative crew, and no design changes were communicated via email -- on that one successful project, all questions were answered in the short term by "I'll revise the design document", followed shortly by a revised document.

Even then it failed on one board because the guy doing that software started writing code without doing a design document at _his_ level -- and when all was said and done, his was the buggiest board in the system, and gave us grief for years.

--
www.wescottdesign.com

The good ones don't give you that blank look. If you read the material on TDD from the drivers of the process, the intent of TDD is to make you think through the detail before you write the functional code. It's not an alternative to really strict software design (see your own example below): it's an alternative to slap-dash "throw stuff at it and see what sticks" sort of design.

Every time I've used TDD for my own development, I've been thankful at some point in the process that I did so. Every time I haven't, I've regretted it. Say what you will, in the real world it seems to be a Good Thing.

And the parts of the code that had to meet DO-178 level D cost 7 times as much as the parts that could be "commercial" quality, while the parts that had to meet DO-178 level C cost 7 times that, all the way up to DO-178 level A, which cost roughly 2500 times more than "commercial quality" code, intended to deliver the same functionality, would have.

--
www.wescottdesign.com

I have seen one piece of C code where I strongly suspect the C was reverse-generated from the assembler code. I can't think of any other reason why there would be a completely unnecessary "goto" into the middle of an if-then-else clause.

It happens a lot and is the cause for many project failures.

[...]

IMO a bad policy. Comment lines do not allow for graphical input such as flow charts, diagrams or pictures.

Probably you guy were lucky. Especially in (civilian) government there have been collossal failures of software projects.

Don't get you hopes up. Someone would have to sign on the dotted line and allocate the funds and that's just not happening. True vision is rare in larger companies and most such applications are the products of huge IT companies. You'd almost have to create everything from scratch, market it, then hope that one of the big guys buys you out.

Over my career I've written umpteen proposals of this sort. Some caught on big time and resulted in major work for me. Most others generated a lot of interest and then it fizzled. Sometimes companies liked the idea, then tried to do it the old-fahioned way with the resources they already had and ... failed.

--
Regards, Joerg 

http://www.analogconsultants.com/

That's a common fallacy. Documents are done in hindsight instead of parallel to the project. The result is that nobody really has time or will power to do it well, a shoddy documentation results and that gets filed. One sunny day things hit the fan.

You can lose a lot of money for not having it. Usually in court or after auditors waltz in. Or when a redesign is needed and due to lack of documentation the only method left is tabula rasa, no re-use of anything, gets expensive.

That's why they hire expert witnesses.

I assume if they hadn't documented it the lawsuit could have had a different outcome.

That job takes a lot longer if the documentation is more or less a loose stack of notes and scribbles.

--
Regards, Joerg 

http://www.analogconsultants.com/

My current design document is 52 pages, and I haven't done the software part yet, or the signal/calibration math, or the FPGA data flow diagrams. The critical path now is to get the hardware done.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

Just so. Unfortunately there is the concept of "regression to the mean", with emphasis on "regression".

Oh, just so. I can't imagine doing anything else! But then I grew up with "doing" hardware and software, and, after a couple of hours in a pub, I can make a good case that there is (or should be) precious little difference between hardware and software ;}

The real world is populated by people that believe whatever the latest demagogue said :(

In an ideal world such people would nevdr be let loose with a keyboard or soldering iron. Meanwhile, back on planet Earth...

I would have been delighted by a few loose notes and scribbles. The schematic was the documentation.

--
Bill Sloman, Sydney

I do a design doc and write the manual *before* I design the product. Otherwise, how do you know what to design? How will the FPGA and software people know what to code?

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

It almost sounds like you know what you are doing before you do it. :(

More seriously, that would be an "issue" where clients change their mind, or you don't have a clear-cut objective at the beginning.

And the "we'll-figure-out-what-we-want-as-time-goes-by" approach that those folks want to adopt ends up being an issue when they start looking at the ledger, calendar and inquiries from potential customers waiting for a product with no clear delivery date or development cost!

"Just throw *something* together and we'll fix it in version 2" (which will, no doubt, be designed in the same /ad hoc/ manner)

Absolutely WONDERFUL environment in which to work -- not! :> (unless, of course, all you care about is a paycheck)

The problem with writing the manual first is that you must write the REAL manual; not just something that PRETENDS to be a manual.

I.e., what are *all* of the error messages? What do they all mean? What are all of the prohibitions and constraints imposed on the user and the device (often a consequence of implementation), etc.

OTOH, do this correctly and writing the code and designing the hardware become straightforward -- almost mindless -- "chores"; you already KNOW what you have to do!

For custom products, the users seldom articulate what they really need. So getting them to accept a manual, with specifications, before we do the design is a mandatory defense against misunderstandings and cost disputes.

You've got to write a manual anyhow, so it's better to do it before the design.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

Huh OK that makes sense. Mostly we make a product and then sell it. And it's easier to write the specs once you've got something working.

I try and put a copy of my schematic, with voltage levels pulse shapes, signals... whatever is needed, into my note book, I'm less than good about documenting changes.... why I dropped this resistor value by 1/2... those are sometimes on bits of paper, which may or may not get stapled into the note book. No one reads my note book but me.... and not even me most of the time.

I make pretty simple circuits though. I can refer all of them back to some app note or AoE figure.

George H.