Computer programmers' habits in electronics

[Ignoramus10397]

A newbie question...

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bullshit. I just start
coding and try to make sure that I have some working prototype most of
the time, and that I do things nicely. Usually things work out okay
and programs do their job quietly, as intended.

Not doing too much "design" also helps when the purpose of the program
is not quite known from the beginning, as it usually happens.

I find it very difficult to change this mindset and do any sort of
diagram drawings or some such when it comes to electrics or
electronics. For example, I put together a pretty intricate phase
converter in the last month, for instance, with two motors, some turn
on logic, blah blah. That seemed to work.

What I am worried about is that if I try to do something involving more
than say 20 wires, I would run into a wall and that electronics is not
the same as computer programming.

So, I am curious if anyone can relate and tell me either just how
mandatory drawing is, and how to get accustomed to it, or how they
make things without detailed plans.

i

 

[[email protected]]

A newbie question...

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bullshit. I just start
coding and try to make sure that I have some working prototype most of
the time, and that I do things nicely. Usually things work out okay
and programs do their job quietly, as intended.

Not doing too much "design" also helps when the purpose of the program
is not quite known from the beginning, as it usually happens.

I find it very difficult to change this mindset and do any sort of
diagram drawings or some such when it comes to electrics or
electronics. For example, I put together a pretty intricate phase
converter in the last month, for instance, with two motors, some turn
on logic, blah blah. That seemed to work.

What I am worried about is that if I try to do something involving more
than say 20 wires, I would run into a wall and that electronics is not
the same as computer programming.

So, I am curious if anyone can relate and tell me either just how
mandatory drawing is, and how to get accustomed to it, or how they
make things without detailed plans.

i

Are you employed, or still a student?

This might work if you're still a student, and your projects aren't too
complex. The story might be different if you're a contractor hired by
a client to design a complex piece of software...

 

[Ignoramus10397]

Are you employed, or still a student?

I am employed, I have been programming for money for 13 years or
so. (not counting the gigs I had as a student).

This might work if you're still a student, and your projects aren't too
complex. The story might be different if you're a contractor hired by
a client to design a complex piece of software...

Yes, if I am hired to design stuff, I better produce design, sure.

i

 

[Jim Thompson]

A newbie question...

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bullshit. I just start
coding and try to make sure that I have some working prototype most of
the time, and that I do things nicely. Usually things work out okay
and programs do their job quietly, as intended.

Not doing too much "design" also helps when the purpose of the program
is not quite known from the beginning, as it usually happens.

I find it very difficult to change this mindset and do any sort of
diagram drawings or some such when it comes to electrics or
electronics. For example, I put together a pretty intricate phase
converter in the last month, for instance, with two motors, some turn
on logic, blah blah. That seemed to work.

What I am worried about is that if I try to do something involving more
than say 20 wires, I would run into a wall and that electronics is not
the same as computer programming.

So, I am curious if anyone can relate and tell me either just how
mandatory drawing is, and how to get accustomed to it, or how they
make things without detailed plans.

i

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

 

[[email protected]]

I am employed, I have been programming for money for 13 years or
so. (not counting the gigs I had as a student).

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.

 

[Jon]

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

 

[Bob Stephens]

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bullshit. I just start
coding and try to make sure that I have some working prototype most of
the time, and that I do things nicely. Usually things work out okay
and programs do their job quietly, as intended.

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

 

[martin griffith]

On Tue, 20 Dec 2005 11:19:01 -0700, in sci.electronics.design Jim

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 ;-)

Woohoo, Nice one Jim




martin

 

[Dirk Bruere at Neopax]

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.

It depends.
I normally start by writing all the drivers that will actually interface with
bits of hardware. That doesn't really take much 'design' in the normal sense of
the word, but it gives me something to flash lights with.

Then I start at the top end and sketch out what classes/functions I need to get
down to driver level.

Right now I'm into a control system being written in C++. It will probably top
3000 lines when complete, but I still do not need a formal design methodology.

I have spent a great deal of time on the control protocol that interfaces with a
PC. That determines the data structures and hence classes. It's all quite
straightforward.

Now, if I was having to collaborate on a bigger prog then formal methods would
probably be indispensible.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[Ignoramus10397]

It depends.
I normally start by writing all the drivers that will actually interface with
bits of hardware. That doesn't really take much 'design' in the normal sense of
the word, but it gives me something to flash lights with.

Then I start at the top end and sketch out what classes/functions I need to get
down to driver level.

Right now I'm into a control system being written in C++. It will probably top
3000 lines when complete, but I still do not need a formal design methodology.

I have spent a great deal of time on the control protocol that interfaces with a
PC. That determines the data structures and hence classes. It's all quite
straightforward.

Now, if I was having to collaborate on a bigger prog then formal methods would
probably be indispensible.

Not necessarily, if you have good programmers to work with, you can
agree on who writes what libraries and in approximately what ways.

i

 

[[email protected]]

From what your saying it sounds like you do most of your designs in
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).

 

[Tim Wescott]

Are you employed, or still a student?

This might work if you're still a student, and your projects aren't too
complex. The story might be different if you're a contractor hired by
a client to design a complex piece of software...

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.

 

[[email protected]]

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

(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.

 

[Tim Wescott]

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

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.

 

[Dirk Bruere at Neopax]

Not necessarily, if you have good programmers to work with, you can
agree on who writes what libraries and in approximately what ways.

The biggest programming job I have worked on was one that topped (I estimate)
30,000 lines. There were two of us on that, and we needed only informal
get-togethers to split the tasks reasonably smoothly.

Of course, what makes the job I am currently working on even easier is that I'm
designing the h/w along with the s/w. However, I *will* be using circuit diagrams!

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[Dirk Bruere at Neopax]

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.

That's the situation I'm in right now.
There is a lot of pressure to get a working prototype. Bugs can be fixed and
documentation done later. Getting money in comes first.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[Rich Grise]

A newbie question...

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bullshit. I just start
coding and try to make sure that I have some working prototype most of
the time, and that I do things nicely. Usually things work out okay
and programs do their job quietly, as intended.

Not doing too much "design" also helps when the purpose of the program
is not quite known from the beginning, as it usually happens.

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.

I find it very difficult to change this mindset and do any sort of
diagram drawings or some such when it comes to electrics or
electronics. For example, I put together a pretty intricate phase
converter in the last month, for instance, with two motors, some turn
on logic, blah blah. That seemed to work.

What I am worried about is that if I try to do something involving more
than say 20 wires, I would run into a wall and that electronics is not
the same as computer programming.

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.

So, I am curious if anyone can relate and tell me either just how
mandatory drawing is, and how to get accustomed to it, or how they
make things without detailed plans.

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

 

[PeteS]

It depends.
I normally start by writing all the drivers that will actually interface with
bits of hardware. That doesn't really take much 'design' in the normal sense of
the word, but it gives me something to flash lights with.

Then I start at the top end and sketch out what classes/functions I need to get
down to driver level.

Right now I'm into a control system being written in C++. It will probably top
3000 lines when complete, but I still do not need a formal design methodology.

I have spent a great deal of time on the control protocol that interfaces with a
PC. That determines the data structures and hence classes. It's all quite
straightforward.

Now, if I was having to collaborate on a bigger prog then formal methods would
probably be indispensible.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

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

 

[Rich Grise, but drunk]

.

I sent her back a note, "Surely Shirley, ..."...

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

Cheers!
Rich

 

[Rich Grise, but drunk]

Are you employed, or still a student?

This might work if you're still a student, and your projects aren't too
complex. The story might be different if you're a contractor hired by
a client to design a complex piece of software...

He's a junk dealer. ;-P