Tab'ed Webapps Can Kiss My Whole Asshole

First, let me say, I love bloglines. I’d be applying to work there for free if I lived in the valley. That sentiment shouldn’t be news to any of you, dear readers.

With that devotional out of the way: I don’t like the new tab’ing up of the Add screen. Previous to adding package tracking (I think), you’d go to the Add page, and see all the different types of things you could add: a raw feed URL, a Topix zip code, Google and Y! groups, LiveJournal users, etc., etc., all on one page. Now, as the below screen-shots illustrate, all these types of things you can add are split across multiple pages.

Jesus! I hate that!

Here’s the screens (click each one for a larger image):

Bloglines Add

This is the default page with, I’m guessing, “the most important” things you can add. Note the “tabs” (in the style of links) along the top, Email Groups, News, Search, etc.

Bloglines Search

Here’s the search tab. As a side note: it’s cool that they have Indeed in there. Indeed is, indeed, awesome (I’m so funny!).

Bloglines Package Tracking

The package tracking tab.

The Myth of “Clutter”

I’ve worked on web applications my whole professional life. This phenomenon of one page splitting into a tab’ed set of pages happens to every application. You’re sitting in a meeting, adding in features, and somebody says, “I think this page is going to be too long! It’ll run off the page! It’ll be too overwhelming.”

Then you argue with this person for sometime, usually having to cover such basic web app things as demonstrating the use of the scroll bar and telling them that, no, we can’t put things in the right click menu. In the end, you (or someone else who just wants to go to lunch) compromises and says, “what if we put tabs in, to split this ‘long’ page up?” Then everyone’s happy. Yay!

Except me, the user: I know how to work scroll bars, and my mind is quick to take in a parse up a web page. I spend, I’d guess, 3-6 hours a day in bloglines, everyday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and, (sorry, God) Sunday. (Hence my passion about it.)

I hate tab’ed web applications. To all you tab’ed web app people I say this: get back in that room and figure out how to make it work on one page. In the mean time, I’ll be back in bloglines reading my feeds ;>

From Slack: The 15% Penalty and Proof by Repeated Assertion

I’ve been reading Tom DeMarco’s Slack. It’s about a lot more than I thought it’d be about (i.e., slack a la Google’s 20% rule), which is great. I love the style of the book: it’s super concise/packed writing in a nice trade-paperback form. I love trade-paperbacks: the perfect size for holding, folding, and copious marginalia. Enough about that banal crap (is that an overly repetivie [irony!] phrase, “banal crap”?).

The pillar of Slack is that knowledge workers are over-worked, and that this causes actual loss of productivity, primarily through (1.) inability to work at a profitable capacity, and, (2.) high turn-over. The first makes sense: if you’re spread thin over multiple projects, each one will suffer. The second has all sorts of hidden/soft costs that will make accountants roll their eyes and managers nod their head in agreement: the training it takes to bring a new person up to speed is immeasurably high.

Here’s the first passage I underlined and dog-eared:

[T]here is never less than a 15 percent penalty due to time-sharing a knowledge worker between two or more tasks. Moving a person who had been assigned to a single job to work part-time on a second exposes you to a loss of at least six hours per week of that person’s time.

The only method I have used so far to substantiate this 15 percent minimum penalty is the time-honored approach called proof by repeated assertion. Its conclusiveness rests on the fact that I have stated that there is a 15 percent minimum penalty and then stated it again (and again and again and again). Although widely used, proof by repeated assertion, you may argue, lacks a certain amount of satisfying rigour. To which I answer, “Compared to what?” Before I waded in, the presumption seemed to be that the task-switching penalty was essentially zero. We see this as companies everywhere assign knowledge workers in fragments, sometimes with as many as eight or ten different tasks allocated to a single person. The prevalence of this practice amounts to a frequently repeated assertion that there is no penalty or that it is so minor as to be ignorable.

If you’re not chuckling at that twisted logic, then you’re not getting part of the joke…ha, ha, ha! Oooo…knee-slapper! It’s funny ’cause it’s true.

Indeed, the point is, it is true: when it comes to this kind of management talk/thinking, if you expect arguments to be won by the use of logic, it’s time to go back to grad-school, ’cause that’s the only place logic is going to work out for you.

As Matt “No More Weblog Posting for Me” Kinman is fond of reminding me, he’s posted a link to a more substantive discussion of the context switching problems, from good old Johanna Rothman, no less.

Notes on Fearless Change

I finished up Fearless Change: Patterns for Introducing New Ideas over the weekend. Here’s a little review/overview.


As the title implies, the point of the book is to help out people who want to introduce change to an organization. The status quo is all powerful, dear readers, and one needs tactics to make large elephants turn direction. I’m not sure if someone’s claimed the truism, but I’ll posit what’s almost a tautology: the larger an organization, the more difficult it is to change. I wanted this book to give me some tips on changing, and introducing new things (“innovating” as we call it) such large organizations. I think it did a pretty good job.

The overall theme is people, esp. communicating with them and working with them, instead of “for them” or forcing them to do what you want. In this sense, it’s a very pragmatic book when it comes to introducing change/new ideas: instead of Platonically relying on the pure truth and goodness of an idea, it gives more Gorgian methods, e.g.:

A wise observer once said, “People will always do what you want them to do if what you want them to do is what they want to do.” But if you are proposing something that people aren’t eager to do, the act of convincing may mean you must present a logical argument with cold hard facts. Unfortunately, research has shown that most of us make decisions based on emotion and then justify those decisions with facts. Your effectiveness as a change agent will rest on more than your ability to talk to people.

Most of the persuasive patterns spring from this line of thinking: cold hard facts are great, but that’s not how people operate, so don’t use that as your only, or even primary, method.

(If the above reminds you of Blink, you’re payin’ good attention. The two books fit well with each other: Blink as sort of a general theory and the “research” mentioned above, and Fearless Change as a handbook for getting around in the world Blink outlines.)

A good example of this is the pattern Big Jolt. This pattern recommends brining in an outside topic-celebrity to speak about the new idea/change you’re trying to champion. Even if you’ve been saying the same thing as this Big Jolt (the outside expect), your co-workers will be more easily convinced by the celebrity than you.

That ain’t rocket science once you read it (as with most of the patterns). What is “rocket science” is being convinced yourself that something like Big Jolt is true and will work for you. With that understanding, you end up resisting the urge to think, “people suck if they need that, why won’t they just listen to me?!” and going ahead and brining in the outside person because it’ll work.

Another example of this pragmatism in in a chapter dealing with getting management/execs on-board with your ideas:

[D]ecision makers are not likely to agree with a new idea immediately. Their automatic responce is usually “no” if they hear about the idea for the first time during a meeting. They must first get the opportunity to voice their individual concerns and ask questions. This is difficult to do in a group meeting and much easier and more effective to do one-on-one.

If you know even a little bit about how old LBJ operated as he was climbing the ranks, all this pragmatic stuff will seem familiar and, indeed, effective. LBJ was a master at getting people to do what he wanted, and had piles of techniques and methods he used to further those ends.


Another interesting theme is that of constant struggling. If you want to introduce change, you’ll have to constantly be working not only towards it, but to maintain it. People in organizations can be lazy: they often want to take the path of least resistance, which is typically the status quo. So, it’s going to be an endless uphill battle to get your stuff going.

More importantly, for the most part, there’s no way you can actually force change on an organization. Instead, all you can do is set the wheels in motion, keep them spinning, and hope other people agree with you. Along with this comes the fact that you’re forced to work with what you have: the mental/will environment of your organization, the people that are in it, and the constraints of it.

A Culture of Change

In slight contrast to this idea of struggling, there forward by Andy Ellis of MSFT contains two interesting comments about the culture of change/innovation at MSFT:

The real passion comes from being expected to have ideas and to champion them, whatever your level at Microsoft.

The most innovative and competitive organizations are those that make the most of their people’s skills and knowledge.

Once you’ve institutionalized a culture of change/innovation, it at least becomes possible to introduce new things, if not a little easier. At that point, you can truly be an innovative and, in hi-tech, thus competitive company. Otherwise, you’re just a stick in the mud waiting to sink.

The Innovation Cycle

The final theme worth noting is the Innovation Cycle, and the people along it. I’m pretty sure The Tipping Point and Crossing the Chasm cover this cycle in great detail (I have those two books on The Stack, but I haven’t read them yet).

The basic idea is that you have, in order of readiness to adopt new ideas:

  1. The Innovators – they come up with the new ideas and are eager to try out new things. Sometimes too eager.
  2. The Early Adopters – though they may not come up with the new ideas, they readily start doing/using them just as innovators do.
  3. The Early Majority – once the idea is proven to be stable enough a large group of people will start doing it. This, I think, is really the tipping point for adoption.
  4. The Everyone Elses – just the normal schmoes who’ll start doing something once “everyone else” (The Early Majority) is doing it.
  5. The Laggards – these people are the last to take up something new: sometimes they never change.

A good portion of Fearless Change covers the care and feeding of the first 3 groups, esp. the Early Majority.


First off, this is a patterns book, which means that after a few into chapters, you have a whole bunch of 2-3 page writeups of a specific problem and one possible solution. Nothing wrong with pattern books, they’re quick reading. The only disadvantage to pattern books (nowadays) is that authors/editors always feel obligated to include a chapter on “what are patterns,” with the obligatory Christopher Alexander reference.

Overall: Not too Shabby

I wouldn’t say this was an over-all must-read like Blink, but if you’re someone like me who’s thirsting to read something, anything, on introducing new ideas and innovations into a large orginization (not just happy platitudes about how orginizations/business should be in that respect), I’d say it’s a good read. Most of the book is extremely pragmatic and nut-and-bolts, meaning that is has ideas and tactics you can start using immediatly. Indeed, as with any pattern book, once you read through all the patterns, you’ll find yourself spotting each pattern “in the wild,” in use. Once you can consciously apply these patterns (and, to a limited extent, react to/work with other people using them), you’ll be much closer to getting shit done when it comes to change.

Yahoo! 360

Thanks to the gracious Charlene Li, I got an invite to Yahoo! 360. If you haven’t heard about it, it’s Yahoo! social-net/blog/collab/etc. thing.

I invited most everyone in my address book that I thought would be interested, but if I missed you, just send me an email or leave a comment.

You can see my Y! 360 page at

(No doubt, and as promised to Charlene, I’ll write-up more as I get a better feel for it.)

When Schedule Matters Most

While jabbering on about this and that, Charles and I also had the realization that very few people talk about what do in iron triangle project management when schedule is the number one goal.

The Iron Triangle states that in software development, there are 3 constraints: schedule (making dates), software quality (how many/few bugs there are), and features (how many new features you can pack in). “You can have two,” the saying goes, “but not all three.” (In my experience, you’re lucky if you manage to get one.)

We couldn’t think of any good studies or writeups of how to do software development when schedule was the choice.

Caught in the Triangle’s Trap

Most people’s trick with introducing the Iron Triangle is to deemphasize the importance of schedule in people’s minds. They’ve taken for granted that the software is going to have a bunch of whiz-bang features (otherwise, customers won’t buy it), it’ll be bug free (otherwise, it’ll get a bad rep, and customers won’t but it), and, of course, it’ll be on schedule, cause we gotta know when it gets released!

The Iron Triangle’s job — in these situations — is to get those people to prioritize those 3 things, and make sure schedule is last. Think of the possible combinations:

  1. Features and Quality: customers will buy it because it’s useful and doesn’t break. They had to wait 3 more months than they originally thought to get it.
  2. Features and Schedule: customers like the features, it was delivered when you told them it would be, but only 50% of it works.
  3. Quality and Schedule: there’s nothing new for customers to use in the software, but what’s there is solid, and it was given to them when promised.

Clearly, anyone can tell you that the first one is the one you want: customers need something to buy (features) and those features need to work (quality). In comparison, when they get those things (schedule) doesn’t matter too much. If I get a car delivered to me on time (schedule) that doesn’t run properly (quality) or doesn’t have a steering wheel (feature), it’s useless to me. I’ll wait.

With all that handled, schedule begins to slip into obscurity, and now we can talk about the exciting aspects of features and quality…<hand-waving> never-mind this schedule thing over here! Move along!

When Schedule Does Matter

Of course, schedule does matter, a lot, in the software world. Oftentimes, it doesn’t matter most to the customer: it matters most to the organization putting out software. Customer’s don’t always really need the software when they think they do; oftentimes they don’t even care.

On the other hand, if you get a reputation of always slipping your date, as a software worker, you’re in bad shape. (Given that customers don’t care about schedule as much as we think they do, I’m not sure why we care about it, but we do.)

As such, schedule is always at the top of the list, despite the fact that features and quality should be there. No literature admits this: they all go over the happy path.

So, long story short, that’s the theme of the software development book I’ve been trying to come up with for awhile: how to develop software when schedule is the #1 priority. I suspect it’d be all about how to cut back on features and quality and still get your customer to want and like the software that’s, at least, delivered on-time, making sure you’ve impressed your bosses with your scheduling wizardry. We’ll have to see.

Who's Responsible for Success?

Mary Poppendieck (co-author of the fantastic Lean Software Development)

started an interesting thread on scrumdevelopment asking who’s responsible for the success of a software project.

Agile: Roles and Responsibilities

The context for this question is the Agile world’s tendency to be very strict in defining the roles and responsibility of people working on software. You have the business people who come up with the requirements and features, you have the programmers who program up those features, etc.

If you’ve ever been in a meeting with 40 people, all trying to define and develop the software, you can appreciate that being strict with roles and responsibilities is extremely pragmatic and effective. “Shut your pie-hole, Stevenson, your job isn’t to pick which features we implement this iteration, you just code it up.” Or, “Christ, Rambleson! You can’t tell the programmers how to code this stuff up! Just tell them the features you want.”

On the other hand, if you’re in a meeting with 40 people, there’s probably an elephant-sized wound in the room, and all the Agile in the world is just going to be a tiny band-aid on that festering sore.

Developer vs. Programmer

I’ve always had a problem with this aspect of Agile (or any process) that separates out people into strict roles. To me, it seems like you’re loosing part of the value of all people involved: some business people are perfectly capable of doing “technical” things. Some code-monkies are perfectly capable of doing “business” things. (Of course, many biz people have for-shit skills at biz, and many more tech people have equally fecal-bound ability at tech stuff.) Point being: the division between business and technical is bullshit; everyone is just developing software.

Charles and I spent a long time last night talking about Agile stuff. One of the more interesting things we talked about was this topic of division of labor in the Agile world. We both came to conclusion that we don’t like it. We’ll be splicing it into some podcasts over the next few weeks, so I won’t spoil it for you.

Defensive Software Development

My evolving opinion is that all this, any process, is all about taking care of the weakest links in your team. When your team isn’t made up entirely of of smart, capable people and/or the organization you’re working for is being irrational, lax, or otherwise a detriment to the development of the software at hand, you need defensive tactics. To me, that’s what most processes/methodologies of today are: ways of protecting yourself/team from idiots and CYA-insurance for when idiots attack.

As such, I have a yet further jaundiced eye towards the division of biz/code. It’s just a defensive move and, as such, a tool to be discarded when it’s not needed.

Back to Poppendieck

Mary provides a great writeup of why the biz/code division isn’t the ideal state:

I think that all really brilliant software is born only when people who deeply understand the technology and people who deeply understand the business need get a “mind meld” in some manner. Often there is one person who has a deep understanding of both areas in a startup company. For on-going success, that meeting of the minds has to be replicated somehow. I’m looking for a team where that meeting of the minds happens because the technical people care deeply about understanding the business and the business people care deeply about understanding the technology.

[From another email:] If the development team members were also owners of the company, they wouldn’t spend their time chasing ideas they knew would fail.

Which Gadget Blog Is Best?

Like Steve, I spend a fair amount of time making sure I don’t read too much (or, at least, I think about ways to not read so much). Along those lines, I’ve been trying to figure out which gadget blog I should read: engaget or gizmodo.

After having read them both for almost a month, I can’t really tell them apart: they both cover the same things. Of course, it’s not like I’ve been spending a lot of time analyzing the differences between the two.

So, which one would you subscribe to if you could choose only one?

Ye Olde AutoLinking Debate

I’m almost done listening to the ITConversations podcast on AutoLinking. I had no idea it was such a controversial topic: but, of course, anything that modifies content (AutoLinking, once a button is pressed, creates links out of addresses, ISBN’s, and other things in a webpage) gets monied interests all fiesty in the head. The main issue is about the control of web published content.

All this stuff was debated back in the mid to late 90’s when frames were (like debated, and then there was app from the late 90’s (ThirdVoice?) that let people add annotations to any web page (how cool was that?). But, it’s still very interesting, if only because Doctorow runs circles around the pro-“content producer” arguments, even deploying the deadly, “yeah, competition sucks doesn’t it…you fucking cry-babies.”