Computer programmers' habits in electronics

I spend probably 75% of my day job time fixing legacy systems problems due to non-design of exactly the type you're talking about. Someday you or your clients will get tired of riding a raft of duct tape over bubblegum and baling wire.

If you're wiring 500 switches to 500 LEDs, you probably don't need a diagram because each switch-LED set is self-contained and there are no interrelationships to test. If you're building a real project, then it is irresponsible to yourself and the client to operate without a design. Lack of a design implies lack of an engineering specification, which means you have no way of knowing when you've finished, and no confidence to answer client questions about usage scenarios.

Complex projects are handle by teams of systems engineers/hardware engineers/software engineers/programmers/verifiers. "Seat of the pants" coding just does not work in this environment. You must have a clearly defined set of requirements at each step. The methodology you use is not as important as the fact that you have one, and everone understands it. Regards, Jon

Yep. Electronics is just the same. Reach into a bag of parts and start soldering. Bridge building is similar. You are almost certainly a troll, but on the odd chance you aren't, I'll bet your code is pretty awful.

Bob

your head and then produce a circuit from it (which I sort of do to). I would suggest that electrical drawings and documentation be produced for all personal and job related projects, and here is why.

I find that once I have an idea of a circuit and put it down on paper (or on a computer) I can better visualise it and make modifications and tweaks to make it work or work better (fewer parts, more efficient, more rugged, etc). Having the circuits documented is also helpful if you want to produce something similar in the future.

For job related projects (especially if you are doing contract work) drawings and documentation are a must. There is nothing worse than when a piece of electrical equipment malfunctions at a site and a technician (or contractor) is called in to try and fix it and no documentation or circuit diagrams exist. Much time and money is wasted (and stress created).

I also find for medium to large jobs that having documented test results on circuit operation and performance (voltage and current measurements, timing measurements, digital scope printouts of wave forms, etc) are useful, especially if the circuit does not work first time. This data is also useful for checking if a circuit actually works as intended, and is a powerful tool for fault-finding the circuits if (or when) they break down in the field.

Unlike software code (which I have also done), electronics have a lot more potential problems which can cause an otherwise fine circuit that works on the lab bench to fail (immediately or after a time) when put into the field (component drift and aging, environmental conditions, noise, harsh or unexpected use by end user, etc, etc).

In the end it really comes down to what works best for you and your employer (althou you only need to be burned once by a project, where documentation would have saved you to realise just how useful a tool it is).

Na, managers love that sort of stuff, because it generates the "work" that they can recognize as being valuable.

Regular employees don't produce much "real work" because they're either "wasting time" with up-front design work that will produce software destined to breeze through SQA, or they're fixing poorly documented designs written by contractors (or themselves, depending on their attitudes). Neither of these activities are seen to be as productive as the "work" of the guy who breezes in and writes poorly structured code with no comments or supporting documentation, then leaves before the s--- hits the fan.

The equation goes like this:

Don't spend time documenting = man-years of work wasted down the road fixing stupid problems and soothing pissed off customers.

Do spend time documenting = longer time before you have blinky lights and motors going "zing", ultimately shorter time to having a product fully ready to foist on an unsuspecting public.

In the guy's defense, I will say that I have yet to see a startup that has really well documented designs. In that case I think it's probably OK to risk a poorly documented design because the equation is different from an established company, going something like:

Don't spend time documenting = man-years of work wasted down the road fixing stupid problems and soothing pissed off customers.

Do spend time documenting = no product at that vital trade show, no customers, company goes down the tubes, end of story.

The excuse that the requirements change has been answered by Extreme Programming. Shoddy work remains shoddy work.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

(gasp) for bridge building too? Maybe for the Army...

Besides the load calculations, think of the seismic and wind gust calculations... I'm getting dizzy already.

That reminds me... I have to get back to work. :)

Interestingly enough folks have been trying to find structured ways to do this with software for decades, with moderate to good success. The current methodology is called "UML", for "Universal Modeling Language". While the "Universal" is more of a comment on the narrow-mindedness of the software engineering world than on the applicability of UML for anything but software, it is a very handy conceptual tool.

It provides, among other things, a very powerful block diagramming language tailored to designing object-oriented software applications.

So you were right all along, and had a dippy and vindicative instructor.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

As a circuit designer I've always liked "block" diagramming of a system before I begin, so I don't create redundant (or useless) circuit chunks.

So I find it hard to fathom how you can write software without some similar organizing scheme.

I once took a course at the community college in Pascal (that will date me :-)

The instructor insisted on using "outlining" which, to me, was trying to write raw code without any sense of direction.

When I kept using block diagramming she got pissed at me and started giving me F's on the assignments, in spite of the resulting code being quite compact.

Then I skipped the final since I could care less about the credit.

So I got a F for the course.

The dean, Shirley something or other, wrote me a letter expressing concern for my academic future.

I sent her back a note, "Surely Shirley, Aren't you capable of reading my records? I already possess a Masters in electrical engineering."

She didn't reply ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
"Winners never quit, quitters never win", Jack Bradley Budnik ~1956

a

The last *major* piece of software I was involved in was the diagnostics for a video-on-demand system. The diagnostics alone totaled over 800,000 lines of code written by 10+ people over some years.

Without the spec (tightly written) and a 'black box' diagram (which I use both for hardware and software, however apparently trivial the project) we would never have got it done. I also designed the diagnostics for the next gen system (massively distributed processes) and helped design the actual system hardware, which helped enormously.

That system, incidentally, was a 'massively parallel system' with up to

320 parallel processors (I love the C construct 'where(x)' :)

We wrote both the host and target code. The host code included not only task control but our own drivers onto our own boards in UltraSparcs which connected to the target. Without the spec and a diagram of what does what, we would have been lost.

That's not to say I haven't done drivers by the seat of my pants, but generally I sketch out what the driver is supposed to do so I (or others) can write the interface to it while I am still debugging the low level driver.

I've done a lot of code and hardware since then, but no code on the scale of that system.That said, doing any non-trivial project without some semblance of documentation is generally bound to have lasting consequences (the 'why is that part there? syndrome).

Cheers

PeteS

Two words for ya: job security.

:)

That reminds me... this might work in certain third-world countries.

Then again, if the house falls down in an earthquake or storm, the locals might just execute the one who built it...

That's fer shuure!!!

Madman Mike

I would not agree, honestly. I just did 3 fairly trivial CPLD designs (all related) that need their own spec document so everyone can agree (you / I will not be the only ones in the code) what the thing is supposed to do. Apart from that, I (like many designers) juggle multiple designs - when I go back to something, it's nice to be able to read the spec document to remind myself of just what I am trying to achieve in the minimum possible time.

There's a difference between self documenting code (a good thing[tm]) that specifies what and how the code is achieving something and a spec document that specifies what the code is supposed to achieve in the first place.

Cheers

PeteS

In what languages are you coding?

My oldest son is a bit of a software guru. He _insists_ that I write documentation as comments right in the code... why did you do this... why did you do that... what outcome is expected... etc.

He's a real stickler for details.

He makes BUCKETS of money... far more than I do, so I'm sure that he is correct.

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
"Winners never quit, quitters never win", Jack Bradley Budnik ~1956

Forget about designing electronics!

John

Are you talking about how programming often involves sitting down and pissing and twiddling with the code until it does approximately what you set out to do, without too many bugs?

In my earlier years, I did a lot of that. I wrote a ray caster pseudo-3D walkthrough program, even with textures (okay, so 8x8 isn't much for a texture, but still), and today I look at the QuickBasic code I wrote and I just think

Huh?

I know I did it basically by iterating a line, segment by segment (yeah, slow) from the viewpoint until it intersects a wall, and that the decimal fraction of where it intersects determines what column of pixels to draw from the texture in memory, and that distance times the cosine of the ray's angle determines drawn height on screen, but damned if I can read the code and figure out exactly how I did it.

And not only that, but once a piece of code is down, whether or not it works "well", it works, so you're not apt to change it ("if it ain't broke don't fix it").

I think this compares well to electronics. Maybe you haven't figured it out yet, but you're new, too.

I don't know what anyone else calls it, but I'd like to call it "simulator syndrome". You start with a basic pretense of a circuit, maybe some theoretical setup that forms the heart of your project. Then you crystallize parts around that, twiddling until it works to your satisfaction. So now you have a circuit, that works, in the simulator. The problem is, the simulator is an idealized reality, and like so many philosophies[*], it can just crumble to a stinking bucket of shit when you print it with real components.

[*] Homer Simpson quote: "In theory! In theory, communism works. In theory!"

Even without a simulator, you can still fall into this fallacy. I personally have built a preamplifier, that worked, by using single base bias resistors from +V to base. You're supposed to use a voltage divider, so bias current is set by that voltage and the emitter resistor. It'll work either way, but my way won't work very well with different transistors (even from the same batch) or across a temperature range, or across much time for that matter!

I think these situations are analogous to the mindless programming I described earlier. It's like using, well hell, anything QBasic at all -- I don't think I've *ever* compiled an .EXE under 30 kilobytes! What bloatware. And you can print "Hello World!" with probably about one thousandth that of just machine code (compiled ASM), a large percentage of that being the message itself. They accomplish the exact same tasks, so clearly you can say they both "work", so what's the difference, who cares if it's 29,970 bytes bigger?

On the other hand, the methodical approach to programming and electronics involves laying things out in convienient blocks and working each relatively discrete unit seperately. Recently (last year) I made a delve into programming, writing a 3D-point-placing program (again, still in QB) to go with a fly-through-space program I made years ago. I started with the original program's engine, but because I need two seperate systems, edit and test, I chucked that in a subroutine, copied its control loop (IF Keyboard$ = "A" THEN ...) and changed, added and removed keypress functions.

Since all the type defs need to be there, plus a few extra, I kept that on the main module. I added a bunch more shared variables, as is required. QBasic sucks at memory (one could argue it is I who doesn't know how to use it, fair enough ;) so for the main data storage I initialized an array using all remaining available memory, about 36kB, and then I merely adjust the maximum index value according to how many points are in the loaded file. When initializing a new point, its value is reset to default (0,0,0) so, although the old data remains in memory, you can never access it.

Since the screen fonts suck on a graphical display, I already planned to add a font I created some time ago. To keep the main module *relatively* neat, I put the display redraw under a sub, which erases, draws all the lines and windows and stuff, then adds text bits (menu, vital information, etc.) and finally places dots representing the verticies in view of each window (all three of which can be scrolled and zoomed individually). Mouse was a required part so I dropped that in...actually I didn't since the program had it to begin with. ;) I did add a function that selects the nearest point when you click the mouse on a viewing pane, not to mention all the clickable areas for entering data. BTW, 657 lines, about 22kb file, 70KB compiled. The 3D viewer alone (which I started from, and which is contained within said) is 9KB code.

But for all of the immense complexity, I completed it in record time, a few months maybe. The progression of 3D programs I've made took years of on-and-off tinkering and twiddling. Likewise, of my electronics, two of my tube amplifiers...

(See, there's a reason the latter is named what it is :) ...have been subject to a range of tinkerings. The pages above should be the latest model, while back schematics may be under my schematic collection. But my most recent project, the induction heater, has been a logical progression: theory model, large theory model, switching model, model sized prototype, final prototype. And in that, I've been keeping the more complicated circuit down to more basic elements.

For example:

- It's like, what the f*ck is this? Besides my habit of drawing tight, confusing schematics, it's hard to see what's going on because there's just so much going on. It doesn't even fit on one screen! (Shut up Jim ;-) This, on the other hand:

is broken into five seperate images, and most of them (especially #3) include a lot of air between sections, letting you see much easier the further discrete circuits: transistor switches, comparators, amplifiers, followers.

The first one I drew as a composite of six sheets of paper I scribbled my first draft on. The second [set] I drew after a few suggestions and revisions, but I think represents the block theory better than the first, which represents chaos rather than the order it's supposed to be.

If you should take any class at all, I suggest a high level math course, with a good professor. Learn problem solving tactics. The thing about math is, you can only do so many things with an equation, so think about it, consider which tool fits the nut the best, then give it a twist. And everything in math is derived from everything else: calculus seems intimidating yet is so wholly intuitive and can be expressed in terms of the most basic theorems and arithmatic. The only thing hard about it is remembering all the identities and how to derive them, but if you think about them you can cover those too. A lot applies to electronics: analyze the situation, figure out what functions you need to perform, then figure out which circuit elements can be combined to serve that function.

I could go on and on, happily because it's such a pleasure to make things and use logic, but alas, I've more or less hit the stopping point of what I wanted to say. If it makes any sense at all...

Tim

-- Deep Fryer: a very philosophical monk. Website:

Well, the first step to correcting a problem is to admit that you have the problem.

Slapdash, slipshod, by-guess-and-by-gosh might get you through opening a file and writing to it, but it's stupid to try to get from point A to point B when you don't even know where point B is. "Gawrsh, let's write a program!" "Whut's it gonna do?" "Dunno yet, but we'll shore find out when Uh'm done with it!"

And all of the roadmaps in the world aren't going to do any good if you don't even know where point _A_ is.

Then start paying attention, and start figuring out, "What is it I'm trying to do here?" and that sort of thing. Maybe read a book or two.

You already know the answer to that one, from experience. If it's more than a few wires, you _have_ to have some kind of a plan.

When you build a house, do you buy a bunch of lumber and shingles and bricks and start throwing them into a pile to see if a house comes out?

Good Luck! Rich

On Tue, 20 Dec 2005 11:19:01 -0700, Jim Thompson wrote: ...

That must have been the pinochle of your academic achievements. ;-P

Cheers! Rich

He's a junk dealer. ;-P