Re: Computer programmers' habits in electronics

onehappymadman@xxxxxxxxx wrote: 
Ignoramus10397 wrote:

A newbie question...

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bull***. 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...

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
.

Quantcast