Log in

No account? Create an account

Previous Entry | Next Entry

Naked Larynx

26 days remain.

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.


( 2 comments — Leave a comment )
Apr. 4th, 2005 06:00 pm (UTC)
My company wants a requirements management tool that not only provides requirements traceability (which they aren't certain they need), but will trigger planning activities in response to scope-impacting changes to the requirements.

Yeah, let's ignore the incremental gain of being able to handle requirements as a group of interrelated concepts and activities and focus on automating a project manager.

Apr. 4th, 2005 11:08 pm (UTC)
How in the hell do they expect a software tool to handle that kind of change? Cripes, the only way I can even conceive of that would be to force each requirement to be an object and link it to a set of scope objects and create a family of logical operators... and that would basically require an analyst to enter the requirements and make sure they were all attached properly, then create rule definitions to handle the triggering.

Hell, tell 'em I'll write 'em a custom one for time and materials.
It probably wouldn't cost them much more than hiring a project manager. :)

Caliber RM will handle traceability, albeit clumsily.

What it seems like they need is a super configuration management utility. Throw in a test suite, debug reporting, resource scheduling, source code control and document live links, and you have the one tool that will solve all process problems. It will even eliminate the need for interdepartmental communication!

Pardon me while I choke just a little.
( 2 comments — Leave a comment )

Latest Month

April 2012


Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow