Pretty much zeroed out in the voice department today. The happy news is
that I made it to the drugstore this morning before work so I could
refresh the pharmaceuticals that allow me to have at least some function
during the day.
Hay-Zeus. Listening to a discussion on GUI design that's going on across
the way, and hearing the complete lack of understanding of what a GUI is
supposed to do makes me think that I should write a book on successful
embedded systems design. Detailing things about layered architecture,
how to divide logical problems among the layers, designing for4
testability, user interface design, modularity, networking, synchronous
vs. asynchronous events, modal vs. non-modal controls, when to choose
multitasking vs. interrupts, why asserts are a bad idea in
mission-critical code, things like that. Basic things like requirements,
analysis, and testing, proof of concept vs. proof of performance,
feasibility, marketing vs. engineering, and maybe even a section on
project management and scheduling.
Gosh, if I only knew someone who had actually written books on computer
topics and had them published, maybe I could get some advice.
(*cough* Rocky? *cough*)
This isn't the first time I've thought about it. It is however the first
time I've really known without a doubt that I know more about the
stem-to-stern process than 90 percent of those around me. And freaking
basic architectural concepts. Out of 70-some developers, there
are only three that could draw an ISO/OSI layered architecture diagram
or actually identify the layers. And we're designing a device that
communicates on a network.
I've come to the conclusion that most developers don't see a need to
understand a system when they develop code. It's been too prevalent,
particularly in the larger companies where the individual developer does
his work in a vaccuum either out of politics or a sparse management
style or a lack of desire on the part of the developer. This isn't the
case everywhere, or for all developers, but it is pretty common. Maybe
it's because software is taught to be compartmentalized and isolated,
and not seen as a system.
And I've seen far too many designs where mistakes were made in the
beginning-- analysis steps were skipped to save time, or documentation
was cut-- and those things turned around and bit those companies in the
ass down the road. It is inevitable as dirt: there are steps that you
cannot skip, they must be done, and doing them early in the
process can save time and frustration.
And using tools properly... I cannot tell you how idiotic some of the
things I've seen are. A requirements management tool does not write
requirements for you. A source code control system probably doesn't have
the tools to properly handle object code, executable code or
documentation. A bug tracking system needs to have more descriptive
information than "doesn't work" added to it.
Ah, I'm just being Mr. Crankypants today. Bromides do that to me.