Wednesday, March 30, 2011

Your Friend and Mine - Mister Ted Dziuba

Just kidding. I only ever heard of the man a few days ago through CodeProject Daily News, so whatever Web 2.0 milieu this guy swims in, I'm not normally aware of it. Having read his one rant about how bad Mac OS X is, I was strangely fascinated, and read some more of Ted's blog posts. This force-feeding of Dziuba included diatribes about NoSQL, a somewhat incoherent critique of people who talk about scalability (food for thought: if you badmouth people who talk about scalability, are you not yourself talking about scalability?), and a potpourri of other posts from his blog archives.

Now, I don't mean to disrespect Ted. I don't know the man, and if I'm lucky I never will. But he is a poster child for a lot of things that are badly wrong with software development, and I mean to point those out. It may be illustrative. One thing I really don't care about is his profanity. For all I know it's shock value, and if it works it works - I doubt he swears at people like that face to face; he'd have less teeth and be in a wheelchair.

Point number one...and this is fairly significant...unless I miss my guess the fellow is on the youngish side of 30 years of age. Based on when he graduated school, maybe mid-20's. Gentle readers, that means that Master Ted is inexperienced. No ifs and buts. Furthermore, of the five different jobs he's had in as many years, he was briefly a webhead at Google (wonder why he left?), participated in the failed (and apparently not failed for the right reasons) experiment Persai/Pressflip, had the brass balls to think he knew enough about anything as a youngster to write tech columns (did he have the Register's Youth Perspectives editorial or what?), got in with another startup (Milo) so he could do the same thing that he blasts other people for (develop Web 2.0 basic CRUD-tech ad magnets), and is now a senior dude with the company that bought this startup (eBay), presumably so they have him on hand to fix the code.

Some of his blog posts crack me up. The implied seasoning of experience in dozens of turns of phrase, the purported vast knowledge of technology (after all, if you're going to comment on something then the reader supposes you've learned through trial and error), the venture into Joel Spolsky territory when he talks about how to interview, and the wise world-weariness evidenced by I Don't Code In My Free Time. Ted apparently has so much experience under his belt that he's already compiled a list of programming things he wishes he'd known earlier (like when? In high school?), he knows exactly why "engineers" (dude, you're not an engineer and neither are 95 percent of the script kiddies out there) hop jobs, and he presumes to know how to spot valuable engineers.

One wonderful quote from the esteemed Dziuba: "Any developer who has been around enough to accumulate valuable experience will have his personal collection of stories that have mad him rage. I have been burned by bugs in programming language implementations, bugs I call "coding slurs". I have gotten the shaft more times than I can count from pathological character set issues that make me want to run for Congress on the platform of requiring licenses before people are allowed to use computers."

Character set issues that burned him more times than he can count? Doing what? Writing a small handful of twinkie LAMP web apps? "Accumulate valuable experience?" Give it a few more years, Ted...then we can talk.

It's not about Ted Dziuba. He himself is irrelevant, except insofar as he's a useful symbol of a lot of what's wrong with the software development profession. Which, to put it bluntly, is that there's way too many superficial Web x.y types out there that are not professional. In a sane world - especially one starting from the premise that the script kiddies insist on being called engineers - this guy would have maybe just transitioned from being an apprentice to being a journeyman, and perhaps a decade or so down the road he'd have his first shot at becoming a master software engineer. A decade or more after that his peers might even allow that he's sort of senior.

Ted, my man, thank you. I mean that. You're a mouthpiece for all the problem children in the industry, and the first step in cleaning up the mess is awareness of the problem. You're helping...albeit maybe not like you expect.

Oh, and Ted? In Java subList Gotcha, you mention "Well it turns out that subList didn't do what I thought it did. I assumed that I just got a new List that contained the elements in the given range of the original." And "read the documentation." Well, yes, Ted, you do read the documentation when using an API. Leastways professionals do. But if you got bit by something this basic, with a fundamental Java interface, then I guess that points to a pattern of either novice or sloppy behaviour...or both. Given that you've declaimed that there are way more important things to do than professional development outside work hours, it looks like both.

Saturday, March 5, 2011

Collaboration Is Missing The Point

MIT Technology Review has started a new monthly topic in Business, entitled Collaboration Tools. They promise to examine why some tools work, and why others don't. They will also be looking at when and how collaboration is valuable.

Think about that last statement. I didn't see it phrased quite that way on Technology Review, but at least a few articles urge caution in the deployment and use of collaboration tools. So that's what they mean, that sometimes collaboration can be overrated. And that means that it's not always necessary, and sometimes collaboration is counterproductive.

A lot of technology companies and IT users are still mesmerized by the Kollaboration Kool-Aid. After all, how can it be a bad thing if as many people as possible are in touch, and always in touch? How can it be a bad thing if people are sharing knowledge 24/7?

Well, it can be a bad thing, and in my opinion often is. An IEEE Spectrum article entitled "Metcalfe's Law is Wrong" pretty much lays some real-world realities on the line. As the article surmises, a fundamental flaw behind Metcalfe's or Reed's laws is in the assignment of equal value to all connections. The authors argue that Zipf's law makes more sense. And intuitively it does - in my work environment, for any given problem I am working on, I can rank the value of collaborating with various people. To a greater or lesser degree only a few connections have significant value.

Let's go one further. It stands to reason that some connections actually have negative value - opening up a social, "collaborative" channel with a certain person may actually hamper my work.This may also depend very much on the nature of the work: everyone has had tasks from time to time where, quite frankly, everyone else is a nuisance and a hindrance to getting the job done.

This happens more often than the vendors of collaboration tools are willing to admit. To hear their user stories everyone benefits by intimately working together all the time. Not true: it's more likely the case that valuable collaboration is the exception, not the rule.

What knowledge workers really need is effective knowledge management (KM). The typical state of KM in enterprises is abysmal, and that's perhaps a subject for another blog. What I'd like to be able to do (and usually have to resort to Google for, in place of something truly effective) is to search for information inside the organization, and not have to disrupt other peoples' time to do it. Collaboration is disruptive, good KM is not.

Unrestricted, uncontrolled collaboration cannot work. If jamming a dozen people into a room without leadership, and letting them jabber at each other to try to figure out how best to solve a problem, had ever worked, then organizations would be doing that all the time. Oh wait...those are called meetings. Sorry.

Seriously, carefully controlled small doses of collaboration are fine. But here's a thought - we've had an excellent IT tool for that, for decades: it's called email. Switch off the email notification pop-ups, and simply ask that people on a team check their Inbox at least once an hour. Do you really think you need more than that?