- Quick and Dirty is forever (S Kendall). One sure way to design
something which will last forever is to start by intending it to be
a quick hack just for temporary use. A case in point: a major semiconductor
manufacturer had a great idea for a hardware product. They whipped
together a 'reference design' using parts at hand with little thought
of production availability, and offered some for sale. Surprise - few
customers wanted to design their own hardware so they bought the 'verfication
module' and actually start using it in products. It turned out that
the main system connector which mounts the module to another circuit
board was obsolete (they had thousands in stock left over from an earlier
project so assumed (see "assume" below) more were
available). Now what? The module had to be redesigned, obsoleting all
the circuit boards already designed for the obsolete connector. Another
case: using discounted, odd lot parts such as discontinued LCDs in
a product. What if your "lifetime buy" turns out to not be
enough? Expensive redesign time...
- Build on only the best ideas "If I have seen further
it is by standing on ye shoulders of Giants" (Newton). Take advantage
of what others have learned - research prior art before charging off
to tilt at your windmill. Sounds obvious -- but it is amazing how many
projects have been started with little or no research done to see if
someone else has already implemented the idea, or tried and failed.
The antithesis of this is " I can't see because of all these @$#%^
giants standing on my shoulders!"
- Put as little "new" in as possible. Hey wait a minute
- isn't this what design engineers are supposed to do? Actually
no - engineers are supposed to solve problems, and not
necessarily with
new technology. Every new module or interface is a potential source
of bugs and errors. The risk increases geometrically as the amount
of 'new' increases. For example - do you want the design of a new product
to depend on development of an unproven semiconductor process or some
new metal alloy (like hard-to-obtainium)? What if those new materials
fall short of expectations or end up costing more than anticipated
- will
that
sink
your product?
What if that snazzy new memory device slips a year, or is completely
cancelled? (This actually happened on a computer graphics project on
which I was a team member.)
- Avoid cutting edge, sole source parts. Oops, wait a minute,
that's exactly what JStamp is. Never mind... Seriously, the only really
new technology in JStamp is the native Java controller. The rest of
JStamp is standard, proven, readily available components, arranged
in a unique fashion. We deliberately avoided using new, ultra high
density memories or BGA packages in the first releases of the product.
- Release often, iterate often - don't wait until everything
is perfect. It never will be. Add a little bit of "new" every
iteration, not all at once. The USA didn't start the space program
with an immediate attempt for the moon, but with a series of incremental
steps.
- Get feedback from real users as soon as possible An excellent
case of this is the open design of the Dallas TINI module (http://www.ibutton.com/TINI/index.html).
This product was designed "in the open" and as a result Dallas
received a tremendous amount of valuable user feedback very early on
in the design cycle. They also released new versions frequently, giving
users a chance to try out the result of their input while they still
had interest in it.
- What users say they want will change as soon as you deliver it,
so plan for this as best you can and get an early version into circulation.
Take the hit on changes before it's all cast in concrete. This is just
a fact of life. No one can really visualize your creation until they
actually see it, touch it, and use it.
- Listen to customers and they will give you valuable information,
often practically designing a product for you (but be prepared for
them to change their minds after they see it). Also, users will usually
not be aware of disruptive technologies (below) and may very well tell
you to design what will eventually be the downfall of your company.
So which is it - listen to customers - or ignore them and look for
the next new thing? Read The
Innovator's Dilemma: When New Technologies Cause Great Firms to Fail.
- Modularize and use standard interfaces wherever practical.
(It is often hard to know where those "practical" points
are.) This applies to hardware as well as software. Then when changes
are requested you can just change one module instead of the whole system.
One reason the technologically inferior PC was o much more successful
than the Mac was that the PC used numerous open, standard interfaces
and encouraged people to design plug-in hardware for it. And guess
what - they did, turning PCs into custom test equipment, machine and
process controllers, etc.
- Make contingency plans for what will inevitably go wrong.
Trouble is, it's impossible to predict what will go wrong in more than
a general sense. Review progress often and be prepared to change course
if your underlying assumptions prove incorrect.
- Use "soft" hardware when possible. Rather
than a board full of fixed logic devices, use a CPLD or FPGA which
can be easily reprogrammed. Would you rather spend half a day writing
new CPLD code, or a week modifiying a board design, then another week
waiting to get it fabricated and assembled?
- Don't assume - it makes an "ass" out of "u" and "me".
Question everything. Put another way, someone has said "Conventional
wisdom may be conventional, but it isn't always wise".
- Plan on modifications and changes since these make up most
of the lifecycle cost of software products. See "How to write
unmaintainable code" by Roedy Green at http://www.mindprod.com/unmain.html.If
you follow all these rules religiously, you may guarantee yourself
a lifetime of employment, since no one but you has a prayer of maintaining
the code. Then again, if you follow all these rules religiously, even you won't
be able to maintain the code!
- Document as you go. Often the process of writing down what
I am trying to do helps me think through the problem much more clearly
than just jumping in and starting to design or code. Take advantage
of the excellent capabilities of Javadoc. I sometimes start with the
Javadoc -- defining the behaviour of a program, and defining the classes,
methods and fields. It's quicker to change the documentation now than
changing the code later. Then I start filling in the code to support
that.
- If you don't have time to write the documentation, you don't
have time to write the code either - if you are sorely pressed
for time (who isn't?) and can't at least write decent javadocs as
you go, then set the task aside until you have more time.
- Undocumented designs are essentially worthless.
If no one can understant what it's supposed to do, why should they
use it? How can they? How will you remember how it works a year from
now?
- Use version control with your software development tools.
- An hour in design can save you ten hours of debugging - so
don't cut corners in the design and think you'll fix it later. See The
Soul of a New Machine by Tracy Kidder, winner of the Pulitzer prize
for non-fiction. This reads like a case study of how not to design
a computer. (How big a presence does Data General have today?)
- Watch for disruptive technologies. The
Innovator's Dilemma by Clayton M. Christensen poses the question
of how a successful company with successful established products
keeps from being pushed aside by newer, cheaper products.The hard
disk drive industry is a case in point. When 8-inch drives ruled,
the 5-1/4 drives were "disruptive" and the established
8-inch companies wound up with little or no market presence in the
new 5-1/4 market. The same story repeated in 3-1/2 and smaller drives.
- If you are a duck, stay out of the elephant pen. (True story).
As one person or a small- or medium- sized company, you will never
show a big company (Microsoft or IBM) a thing or two. Don't commit
market suicide.
- Great ideas are a dime a gross. Great customers are
what you need to thrive.
- Let the desired function drive the choice of technology, not
the other way round. Don't use PICs to build a supercomputer just because
that's what you know and love. This is another hard one for engineers.
We tend to be enamored with some technology and try to apply it everwhere.
Don't pound in screws with a hammer just because you have one in your
hand.
- Simulators don't. If simulators accurately modeled the world
we wouldn't need prototypes. Why? See below... A corollary to this
is "digital signals exist only on paper, everything in the physical
world is analog".
- Instrumentation changes the behavior of the system under test. It's
a variation on the Heisenberg uncertainty principle: The more precisely
the position is determined, the less precisely the momentum is known
in this instant, and vice versa. --Heisenberg, uncertainty paper, 1927.
See http://www.aip.org/history/heisenberg/p08.htm --
Heisenberg challenged the notion of simple causality in nature, that
every determinate cause in nature is followed by the resulting effect.
Translated into "classical physics," this had meant that
the future motion of a particle could be exactly predicted, or "determined," from
a knowledge of its present position and momentum and all of the forces
acting upon it. The uncertainty principle denies this, Heisenberg declared,
because one cannot know the precise position and momentum of a particle
at a given instant, so its future cannot be determined. One cannot
calculate the precise future motion of a particle, but only a range
of possibilities for the future motion of the particle.
- Try something three times before you give up... Don't say
it can't be done unless you've tried at least three times. Don't be
like the swimmer who made it half way across the English Channel and
turned back because he didn't think he'd make it.
- ...and know when to cut your losses and move on. Eventually
the best thing is to throw in the towel, cut your losses, take what
you've learned and move on to another idea. If you just can't get things
to work, are you designing in too much 'new' at once?
- Don't make crap. There are already plenty of crummy products
-- don't create more. Create things you will be proud to sign your
name to. Create products which are fun to use. You want people to swear by your
product, not at it.
- Information is more powerful when you share it, not when you
hold on to it. This philosophy is the antithesis of the cold war which
was all about maintaining secrets. Will Open Source triumph? See The
Cathedral and the Bazaar by Eric Steven Raymond at http://www.tuxedo.org/~esr/writings/cathedral-bazaar/,
an interesting appeal for open source development. However, according
to the author "Enjoy -- but be aware that I have sold O'Reilly
the exclusive commercial printing rights." Hmmm.
- Keep your own council. Don't just blindly follow anyone's
advice (even mine!). Develop your own judgement. How? "Good judgement
comes from experience. Experience comes from bad judgement." (Jim
Horning). Learn from your mistakes and the experience is not wasted.
- Have fun if possible. Life is short. If you enjoy what you
do and you make a pile of money, great! If you don't make a pile of
money and you still enjoy what you do, then at least you are happy.
If you don't enjoy your work, all the money in the world won't take
away your misery (though it will probably help a little).
- Keep what really matters in mind. When it's all said
and done and we're all long dead, will anyone care about most of the
stuff we've worked on and sweated bullets to make? Find out what really
matters to you and hold on to that.
- Have a hobby which could be an alternate career. This just
sounds like common sense, plus it will make you a more interesting
person.
|
