In some ways, the mixture of silliness with devastation makes a lot of
sense. Or I could just be insane.
I long ago stopped expecting good decisions from work. It's not that
nobody thought about it as I once believed, it's that those who brought
up the issues were ignored. Fer instance yesterday in a design meeting,
I had to bring up the reminder of limitations of system RAM; this device
only has 64 meg of RAM total, and this particular piece was heading for
the use of ten percent of that off the top.
Really, there is no need to maintain all of that data in RAM. It can be
determined programmatically what specific data is needed at any given
time, and only load that data.
Quick example: a GPS map device may have a base map that is 64 Mb, but
it doesn't need to load all of that map into RAM to display a map of the
coordinates, all it really needs to load is the area around the
point at which the user is located. It takkes some intelligent
design and some smart bookkeeping to know how to chunk the data
so it can be loaded up in smaller pieces.
Unfortunately, one of the core design choices of the system was to put
everything into one file. So now instead of being able to
chunk the data and handle random access, any kind of chunking and
retrieval algorithm needs to be written into an XML schema.
So, there is an "issue". A meeting to talk about the issue has been set
for next Wednesday, the 20th, when I will have 10 days remaining. I will
try to put forth the idea of chunking, which will likely blow the minds
of those who have only written linear data.
Though you'd think that a "spatial library" would consider spatial data.
Of course, I would have also considered complex polygons in the polygon
definition and what they might do to your calculations (like area).
Got to surf through someone else's code today for a while. I am reminded
that I do prefer simple over complex for very good reasons.
Sleepy. Would like to be napping.
Did an architectural analysis (a quickie) of a system this morning.
Trying to provide someone who is not technical (he's a money man) with
technical details of a product, and point out some possible pitfalls.
I've already designed a very similar product, and I know from experience
what is needed for it, as well as the level of complexity that it's
going to require.
"How hard can it be... Go to the moon, get some rocks, come back.
My deft analysis will do one of two things: it will put me in a good
position for the design gig since I've already done a lot of the advance
work, or it will boot me out of the running because they don't want to
hear that it's going to be this complex. And in that case, I'm better
off not being a part of it.
It's like GUI design. I try to tell people that have never done GUI
design that they are really better off buying a package like PEG rather than trying to design
"How hard can it be? Draw a button on the screen, figure out when
it's pressed, handle it. Simple."
Until you try and handle multiple screens, and redraws, and Z-order, and
whether a screen object is "dirty", and modal vs. non-modal dialogs, and
Little things, like late in the project when the client wants to add
this neat little logo animation to the screen when the user turns the
device on. It's such a small thing.
"How hard can it be?"
That question will be burned into my tombstone. Right next to "why would
you want to do that?".
See, the user interface is the thing that everybody sees. It's the thing
that everybody wants their fingers in, and pretty much everybody feels
they can design a GUI.
Hardware user interfaces are even more fun. What do you do when your
design calls for five switches to enter data and navigate menus, and in
the final wrap, one of the managers decided to cut costs and knock you
back to three switches?
Or when you decide to use an operating system in your product, and that
OS does a lot of stuff with a console (cough Linux cough), don't short
me a 75 cent part that is all that stands between me and having a
Wow, when did I get so cranky?