I have a funny habit with our code in the front end, where if something’s just too complicated, but i cant see the better solution yet, I’ll give its pieces long descriptive names. It’s basically so they’ll stick out later, we’ll think ‘why is this thing so ugly and complicated’, and it’ll help us remember to revisit it. (btw, I’m not claiming that this is good development practice, it’s just a trick i use, faintly reminiscent of the blue-wire red-wire stuff in the Mythical Man Month).

So anyway, I bring it up cause Johnvey saw one of it’s cousins out in the wild, taking the whole concept to an extreme. Check it out.

Arguably though, this is so extreme that it’s not reallyDescriptiveNames at all, but closer kin to a sort of passiveAggressiveWorkplaceSabotageAdapter.

There’s lots of subtle things that are required for good user experience. Simplicity, speed, comprehensibility, consistency. These are the core value of any software, and there’s a spectrum on which they’re at the other end from ‘Features’.

Features are cool. They make you sound smart. Whether you’re a customer talking to a sales guy, or an engineer fleshing out an idea you had. New stuff tends to show up in sentences as the word ‘feature’. It’s exciting. Sure it has a certain cost in speed or something. It tends to not color entirely within the lines. But that’s OK. It’s new, therefore it’s cool.

Jumping forward many years though, everything at some point was new, and gets old and those costs start to suck. After a while these intangibles have pretty much been sacrificed away and you’re in large-company hell, sitting in endless meetings trying to figure out how and when everything got all bloated and slow.

So, we’re trying to swim against this current as we scale (no kidding). We’re trying to prioritize speed and simplicity. We’re trying to keep talking to users in the trenches. We’re fighting off checkbox-itis, we’re trying to have new corner-case features built in offshoot, quasi-standalone manners, we’re trying to use the extensible architectures we have, and create more of them when needed.

Im a pretty nostalgic guy, so hanging out with me there’s a lot of ‘back in the day’, ‘onion on my belt’ kind of stuff. You have been warned.

So my history at splunk — I started here in March ‘05. First UI Developer, inheriting the front end built by our notorious founder Erik Swan. They brought me in as a dHTML guru and gave me free reign (crossed fingers notwithstanding). But for better or for worse Splunk has always been pretty different on the client-side. Even the alphas and private betas all were all client-side XSLT and had that holy crap moment where you wonder why the hell everything is clickable and lighting up on mouseover.

Then during the sprint to 3.0 we ran off in even crazier directions, and did all the things we’d talked about doing, but held back from (eg endless pager, free form charting in Flash, rethinking the timeline interactions, replacing the tabs with more compact layers).

From this point forward though, there will be more building out and less building up if that makes sense. ie no more monolithic single all powerful UI, but rather links between quasi-standalone bits. And on the monolith instead of bolting on new features Instead we’ll be solidifying things, cleaning, improving, fixing.