Quiet-time is not down-time; can developer-brain translate into
It's been a while since I posted, and although I might claim that
season has begun, it's not entirely
accurate. As I have alluded to before,
I have been making some major technology strides while simplifying my
admin tasks (trying to avoid web content like this)
and laying the groundwork for other projects. Well, I've come to a
stopping point, time for some retro-introspection ...
- If you have any developer background, you can empathize with
my urges to rewrite the whole thing (if I knew then what I know now,
yada). However, we gotta take the business value out when we can, so
it's in production and delivering benefit. Now, before you think me a
sellout, check out the comments in this subset; I holdout
for engineering nirvana (and future work during "all that free time")
by taking copious notes to myself for all those great ideas that I'll
get to some day. Sooner or later I will get to them, but it's
worthwhile to capture the ideas now, make improvements later.
- Another parallel to "real life"; a huge amount of time spent
over the last few weeks on foundational technology, and no tangible,
visible results in the site. This is very much like many projects that
all corporate IT projects have to deal with - the kind of projects that
make articles like this
a tad frustrating. No, I don't think the author is incorrect; I do
think that there is not enough attention paid to the integrations
requirements of applications like Basecamp
(project cost accounting or HR interface?) or Salesforce.com (Customer lists
and product catalogs?). Of course, I do think that all in IT should
find time to play with technologies such as blogs, wikis, ajax, etc.
- I've mentioned these
blogs before as well - lots of good
coding / developer insights, more hard-core developer than I but still
able to make some good business / real world insights. As I dive more
into creating neo-classical web apps of my own, with dreams of bigger
things, I like to have others point out some Aha's for my benefit ...
has some neat insights about simple / fast protocols / designs, how
the web has significantly impacted how people percieve / understand
stuff, and how the database universe may be the next to get impacted.
The referring post
picks off some additional notes on simplicity of design.
- Haack makes
some good points about differentiating between
- the lure of Ajax notwithstanding. Also, some good (obvious? maybe,
but someone had to point it out) points about the certain level of fragility
of web-based apps. Again, something the internal IT groups should be
able to understand, and help the business understand - but not to
avoid the Salesforce.com's of the world, just to set the expectations
I also have to drop in a mention of this post, on another
developer-friendly, business-insightful blog, which recalls (for me)
a project / request prioritization database built IAPL.
We described the problem politely as "can't get 10 pounds of Dirt in a
five pound bag ... maybe six if you push real hard, but that's it".
Anyway, the database / request list became known as the Dirt Bag, and
reports, formal meetings and memos all proudly featuring this name
became the norm. We put it together with some quick and dirty tools,
made it visible to all using web technology, and got real business value
with minimal development effort and expense - not entirely pretty, but
elegant, efficient, and useful.
If that's the final summary of any projects / products /
applications you work on, consider it a major success.