…research has also found that multitasking contributes to the release of stress hormones and adrenaline, which can cause long-term health problems if not controlled, and contributes to the loss of short-term memory.

I spend a lot of time in front of my computer every day. I discovered that over time, I have added so much attention-stealing stuff to my main work environment that I feel constantly interrupted. You get growl notifications, tweets, new email sounds, new email icons, RSS feed notifications and IM alerts. When you are reading stuff on the web you are constantly bugged by the latest in advertising technology.

So, starting a couple of weeks ago I decided to remove attention-stealing stuff from my work environment. A short list so far:

1. Disabling Growl notifications for everything but really important stuff. Done!
2. Turning off new email notfications for Outlook (on my Windows computer at work). Done!
3. Reduced ads in internet content by installing Adblock plus in FF3. Done!
4. Removed MailPlane icon from taskbar. Set “Do not disturb” mode in MailPlane. Done!
5. Turning off IM for long periods of time during the day. Done!
6. Scheduling RSS reading to specific time slots during the day. Hard!
7. Turning off notification sounds in Windows. Done!
8. Hiding the windows taskbar to get rid of spinning mini-icons in the right-hand corner. Done!
9. Turning off yellow alert popups from stuff in the Windows taskbar (like “A network cable was disconnected” – who the hell decided that that was a brilliant idea!?). Not sure how yet.
10. Creatign a consistent editing environment for blogs and wikis with the Universal Edit Button. Done when they’ve fixed the Delicious extension incompatibility.

I am feeling a lot more focussed already. The biggest improvement was from turning of new email notifications in Outlook at work.  I guess the experience is similar to what people are getting from the pomodoro technique.

The next step is to reduce clutter in my blogs to stop annoying other people. Mark Pilgrim gave some interesting tips in a blog post a while ago and I have implemented some of them already. Who the hell needs a visible RSS link (or RSS for that matter, now that we have Atom)? I am thinking about removing the whole category list as well. Do people ever click items in the category list?

It would be great if all apps could share a standard API to set a “do not disturb mode” toggable via a keyboard shortcut or a small timer app that allowed you to schedule this mode throughout the workday.

It presents some information that is different from how the Standish Group defines success in their often refered to CHAOS report. The Standish Group assumes that success is the traditional “on time, on budget and on scope”. In many ways this does not make sense as an estimate of time and budget are made when the least information is available (early in or before a project starts).

In Scott’s survey the following success factor priorities emerged:

• “Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.
• Scope: 87.3 percent said that meeting the actual needs of stakeholders is more important than building the system to specification.
• Money: 79.6 percent said that providing the best return on investment (ROI) is more important than delivering a system under budget.
• Quality: 87.3 percent said that delivering high quality is more important than delivering on time and on budget.
• Staff: 75.8 percent said that having a healthy, both mentally and physically, workplace is more important than delivering on time and on budget.”

Comparing Agile with other development methods

Based on these success criteria the survey investigated the success rate of different development methods:

A small step, but apparently Agile methods have the upper hand if the study is correct.

The missing pieces

What I still think is missing is a study that actually measures the outcome of a project after it was put into production and compares this with the desired effects that were envisioned. Neither the Standish Group nor Scott’s study on success factors seem to cover this.

• How quick was the return on the investment (if the goal was to increase revenue and/or reduce cost)?
• Were all of the desired effects realised?
• Were all the developed features used in a way so that they contributed to realising the desired effects? (think “reduce waste” if you are into Lean or “usability” if you are a human factors kind of person).

Measuring the above items would give more insight into the true success rate of a project rather than measuring the highly subjective “do you think is was successful with regard to factor X”? The only problem, I guess, is that few projects detail the desired effects in a way that is measurable in isolation from other factors in the environment (e.g. “the economy”).

The above items would also make it clear that the usability perspecive should be included from the start of a project.

So no, we don’t hire architects. We hire developers. In a small team, there is no room for management deadwood.

I agree completely. My view is that the title “Software architect” is a misnomer for what most architects in the software industry do, or at least what they should be doing.

It is part of the weird trend that career advancement means getting away from actual programming for some reason. Maybe that is part of a bigger problem when the only way to get a higher pay is to become a manager of some sort? A couple of years ago, most programmers I knew aimed for a project management position. Programming was a dirty job that you had to put up with during the first years in consulting.

When my title was “business analyst” I tried to do as much programming I could and I haven’t regretted that for a moment. In fact, I believe that more people from the business side should get involved in programming to get a better understanding of the fundamental principles. For example, it would be great if business people could write their own acceptance tests and with the booming trend of DSL:s you will probably get involved anyway.

If you’ve made the transition from a hierarchical environment to an agile, self-organizing team, you know what I’m saying. You won’t ever want to go back.

Absolutely. It is the same thing as discovering things like Ruby/Python/Rails: it makes you wonder what the hell you were doing earlier. In many ways I feel sorry for young software developers that go straight into Rails or similar frameworks today. They are not as appreciative as the rest of us:-)

At a recent Scrum training session Ken Schwaber said “it’s all bout telling the truth”. Philip’s post contains some interesting quotes related to this topic:

“When a vice president in the Windows [Vista project] asks you whether your team will ship on time, they might well have asked you whether they look fat in their new Armani suit.

“[...]the intrepid managers finally understood how to get past the dilemma. They simply stopped telling the truth. -’Sure, everything fits. We cut and cut, and here we are. Vista by August or bust. You got it, boss.’ Every once in a while, Truth still pipes up in meetings. When this happens, more often than not, Truth is simply bent over an authoritative knee and soundly spanked into silence.”

Didn’t Microsoft adopt Scrum a year go? Maybe they skipped the part about transparency. Granted, the Windows Vista project may be one of the more complex software projects to date, but how many VP:s do you really need? And even if you do the waterfall dance, there must be some insight into real progress, even for pointy haired bosses?

Update: Apparently too many readers turned his blog post into the standard Windows/Linux shootout which made him remove the interesting parts. Google cache currently has the original.