In spite of all the PDA (Public Displays of Agility) among the agile hippies (“make love, not specs”), some teams/divisions/companies still cling to the old waterfall-like processes. All well and good… even the most fanatical agile hippies admit that agile is not for everyone. But often enough, a team finds itself needing to be more dynamic and responsive to change, while afraid of the big bad buzzword “Agile”. These teams are what I call “agile in denial” (AID).

Signs of an “agile in denial” team:

• They write big or multiple functional specs, but keep changing them until the feature ships
• They have upfront scopes for each release, but end up dropping or modifying large chunks of the said scope as the iteration progresses.
• They designate “feature freeze” dates, each of which is preceded by a mad rush to implement as many features as possible, however shoddily, and put off quality control and/or bug fixing until after the feature freeze.

The detriments of the use of megaspecs to try to cement fluid requirements have been explored well enough – mostly teams end up losing valuable time and resources making (and committing to) plans they will end up not following. But when a team tries to maintain feature freeze dates while succumbing to variability of requirements and scoping, all hell breaks loose.

Let’s do a word problem together: Pretend you’ve entered a very expensive gourmet all-you-can-eat restaurant. Every delicacy you have ever dreamed of is spread out on the buffet line before you. Just a couple of snags: First, an hour from now the restaurant will close and you’ll have to end your meal. And second, ten minutes from now the buffet line will close, so you have only ten minutes to fill your table with all the food you plan to eat during the meal. Question: what percentage of the food brought to the table during the first ten minutes will be consumed by the end of the meal?

A delicious, if unnecessary parable. Feature freeze dates are great if the requirements are firm and the scoping is realistic. But when the scope is prone to change as the work progresses, a hungry PM will almost inevitably succumb to temptation to fill his table with many delicious features from the buffet line prior to the feature freeze, without thought as to whether the team will have time to eat and digest (debug and QA) the selection thoroughly before the release date.

And so we reach the fourth and most tragic sign of an agile team in denial:

• Their releases advertise many new features, but are full of bugs in aspects new and old. Releases often cannot be used to satisfaction until a patch or two has been provided.

See here. The addition of user names is the big story, but burried inside is the change of the URL format. Every user profile will now have a true RESTful URL.

Somewhere, the ghost of Roy Fielding is rejoicing. Most likely inside Roy Fielding’s body.

It seems obvious enough: if you’re going to post content into a platform that will overlay its own graphical elements over yours, you might want to test how it looks with the overlays. I saw this gem of an ad on my Facebook sidebar. Glad I’m not employed by TNT:

This is post is a bit winded, so I’ll slap the moral up here first. It’s a reflection on one user’s struggle against an unfortunate (lack of) usability design. Here’s the gist:

Read the rest if you want the touch-feely stuff:

I spend a lot of my free time (and disposable income) on making music at home – writing, recording, producing – all of it on a computer. I often think of the first time I tried digital music creation: I had to make a 64-bar backing track to a piece of a Russian pop song for performance by a sketch comedy group. I had some college instruction in musical theory, composition, and orchestration, but had never arranged a pop song, especially on a computer. I had procured some software I’d heard of, geared specifically for home users. It looked something like this (click thumbnail to expand):

Meet Cakewalk Home Studio 2002. Never before or since had I felt so vulnerable in undertaking a creative effort. I was a new kid coming into a big man’s world of electronic music, and everyone who got in before me seemed to find his way around just fine. Each minute spent working on that track seemed like a concerted attack on my confidence. Did I bite off more than I could chew? Could I get something done even if I didn’t understand every button and slider? It seemed as if an understanding of the problem domain, music, was not enough… The application demanded its own understanding.

So why do I discuss it here? If you wanted to get into digital music today with the same product family, this is what you would see:

This little gem, Cakewalk Music Creator 5, will ship this Tuesday and costs $40 on Amazon. How many differences can you spot?

Curvaciousness aside, for a program geared toward novices, everything comes down to one big question: “How essential is this?”. All those extra sliders on each track, all those textboxes and toolbars – all can be done without. They’re simply hidden until needed. If you feel you need something that’s missing, you can click around or look in a help file to find it. But you don’t have to feel intimidated by what you don’t need.

The reduction of the starting UI to the mere essentials is what makes all the difference. But if you think this is common sense that goes without saying, consider the Office 2007 ribbon.

The ribbon was intended to help newbies. The intermediates and the experts were doing just fine with the menus, thanks. The intention was to provide quick immersion into as much functionality as possible, to expose features that novices would otherwise not find. But when you do that, are you not also exposing functionality that they might not need? What percentage of Microsoft Word users use bold face at some point? Do you think nearly as many people use box borders? Or sorting? For the life of me, I have never used the text sorting function in a Word document. So why are all of these features equally visible at startup? Do you think an average user is more likely to use sorting than clipart? I don’t. And yet sorting is available on the Home tab and clipart insertion is not.

So when designing for new users, don’t rush to divide features by their function. Rather, divide them first by their necessity. Keep the essentials upfront and tuck away the rest until needed. That’s how you properly welcome the new guy.

Today Giveawayoftheday.com is serving up PPT2Flash, a utility which, if you haven’t guessed, saves PowerPoint presentations as Flash. It took me all of 30 seconds to realize what a piece of fecal matter it is after opening up an old slide deck at random:

Original PPT slide section:

Resulting flash version:

The saddest thing of all is that the version made available is 4.8.0.7 – this is not some early pre-alpha that was never tested. Simply put, it was never tested properly.

Remember, kids, every application and module that accepts or displays formatted text must be tested with (a) special and foreign characters, and (b) all available style modifications (including shadow, outline, strike-thru, etc).

I have written an article discussing the practical applicability of wizards and the potential for their misuse. You can find it here, on the blog of Merlin, an open-source wizard framework for .NET.

It’s amazing how the same bunch of cronies can keep blabbering about the same old stories and keep getting new revenues. Having gotten bored with blogs and anthologies, the speakers and organizers of the No Fluff Just Stuff tour now have a magazine. The articles comprising the inaugural issue are:

• Intro to Functional Languages
• Message Driven POJOs: messages made easy
• So You Want to be Agile?
• A Case for Continuous Integration

While you’re at it, how about some other breaking stories like “A Case For Avoiding Computer Viruses” or “Turning on Your Computer – a field guide” or “Hello, World in Three Lines or Less!”?

We all know a manager can’t just ask his reports “how am I doing?” without receiving a reply that is at least partly tainted by a desire to please. So as an engineer who’s had quite a few managers by now, I’d like to volunteer some observations about things I’ve seen great engineering managers do to create better relationships and deliverables. I can’t vouch for other engineers, but I think this is what they’d tell you if they were high on truth serum:

1. Engineering experience required. No way around it. If you haven’t been an engineer yourself, you will simply not be able to heed the suggestions that follow. You will also lack the “street cred” and the common ground that separate a leader from that dreaded four-letter word “boss”.
2. Laugh at yourself. We all know the stereotype, however inaccurate, of the clueless, lazy, bureaucrat manager, whose paycheck is as high as his usefulness is low. The easiest way to shed that image is to mock it openly. Joke that you can’t really do something because you’re just a stupid manager. Do an impression of Gary Cole’s character from Office Space. Regardless of how accurate or atrocious your impression is, the message is the same: I hate useless bureaucrats as much as you do.
3. Care about the code. Give suggestions about the code. Ask questions about it. Participate in code walkthroughs or volunteer (but don’t demand) to do a code review, when time permits. Listen to explanations and learn any new technical tidbits that your engineers bring up. The benefits are twofold: first, getting near code lets you and the engineers talk about what matters the most to them in their job, thus boosting your credibility and demonstrating to the engineers that you are “one of them”. Second, if engineers know you care about the design and quality of their code, they will too.
4. People over process. An old agile mantra that still is not applied even by some who know it. In the eyes of an engineer, process is something evil bureaucratic managers cook up to make themselves feel important. After all, if you’re not the one doing the work, why should you tell us how to do it? Thus, make sure processes are born organically, by group decision and consensus. When you must establish a process, or indoctrinate a new engineer into an existing process, make sure you explain all the motivations, listen to all the objections, and do your best to elicit buy-in. An engineer that considers a process to be a rubberstamp, may provide only demonstrative compliance. And it never hurts to question the value of a process already in place. Ask the engineers now and then, “is this working? Is this helping or hindering you?”
5. Regular face time. This one seems obvious – talk to the people, one-on-one, regularly. One engineering manager I had did this by scheduling monthly one-on-ones with all of his reports. That might be sufficient if you’re leading an army of robots, but humans and human relationships benefit from frequent and recurrent contact. Even if you just stop in the hall or drop by the cubicle for five minutes and ask “how’s it going?” you’ll keep yourself in the picture and reaffirm your presence on and your involvement with the team.
6. Meetings aren’t (always) the answer. How often have I seen (and heard of) meetings where one person is discussing his work with the leader, and the rest are sleeping. I am fiercely skeptical of the value of such meetings, particularly if the team is large. In that case, I’d limit the duration of such conversations (as in Scrum), or just talk to the team members one on one. You get more meaningful interactions (see previous point), and no one is snoozing or doodling.

Some of the aforementioned points call for a certain degree of involvement in the work of engineers. Some may argue that good engineers can work independently and a manager shouldn’t have to babysit. A manager should be able to trust his team to get the job done well. Certainly, many engineers can and do work pretty well independently (present company included). But how will that team-leader trust develop and grow without constructive and regular interaction? If you trust engineers with whom you do not speak regularly and whose code you never see, you cannot vouch for the quality of the code or the skill of its authors.

At the end of the day, no quantity of great engineers can save a poorly-run team. Great teams need great leaders. Where I work, we have some fantastic engineering managers, but I often hear stories from colleagues outside that make my heart twitch.

Dear managers, if we do our best for you, please return the favor.

Take a look at the “Executive Orders” section of whitehouse.gov. They actually have added Presidential Memoranda, whose absense I tiraded about in my last post. I’m not sure if I’m the only one who sent comments calling for their publication (probably not), but that doesn’t matter… what matters is that someone actually listened! The memoranda weren’t on the site for the first several days of its uptime. And unlike proclamations, they weren’t given their own section. So it seems they have been tacked on to “Executive Orders” as an afterthought, quite likely in response to feedback.

It’s an incredible feeling to have been heard by one’s government. Let’s hope we all get that feeling more often. I think we just might.

I’m sure I wasn’t the only one who went to the new WhiteHouse.gov site today to see it in the Obama administration’s rendition. After all, the new administration promises to speak and to listen to the people directly; a promise of which the new site is a big part. And a promise which, on the first day, was already broken. Twice.

First, there is President Obama’s first order – nothing major, just the expected halting of the last-minute regulations of the previous administration. The real news is that this order appears nowhere on whitehouse.gov. Even if the “order” in question is just a memorandum to federal agencies, such notes are exactly the kind of document that a truly transparent administration would make public. If a president is happy with an agency’s performance, we want to know. If the president is unhappy, we want to know. If the president wants to adjust the goals or workings of an agency, we want to know.

And we want to know directly. Not from private news organizations, which are subject to editorial control. We want the words straight from the horse’s mouth, especially since we’re the ones who put the horse in his stable and are paying for his hay. So like the good citizen that I am, I go to the Office of Public Liason page, fill out the comment form, click “submit” and whoops! I’m told I have not chosen a subject when, in fact, I have. Just a bug, no doubt, all the IT people are probably out celebrating. I understand. But Barack Obama has become such a symbolic figure that it is easy, nay, tempting to interpret this occurrence as a symbolic gesture. The administration falls flat on its promise, and refuses to hear when citizens complain.

Or maybe the past eight years just turned me into one heck of a cynic.