Eventyr

Journeys over Features

Rather than thinking about vertical functional silos, we should think about horizontal slices through the functionality. Slices that support customer journeys. We can start with simple journeys to start and build complexity as we prove our process and new platform, mitigating technical risk as we progress. [...]

    "As an aspirationally clueless I want say what I do and how I live my life and have a suitable phone selected for me."

OK, not the finest story, but you get the point. This story might take elements of the phone selection and tariff selection functional silos, but just enough to realise the required functionality. Because we are building around customer journeys, just enough to realise customer intentions that support those journeys we build only what is required. We are not building by feature list. We don’t over promise and under-deliver. We are building trust with all stakeholders. Surely this is the better way to build software, thinking about customer intentions and incrementally delivering to support more complex customer goals. Sadly, people all too often get fixated by feature lists. Because that is what they are used to. Because that is how products are sold. But isn’t there a marketing 2.0 where we sell experiences and go beyond the product.

Ditch the feature shopping list. Think customer journeys  by DancingMango

Note to self

Hmm, a lot of links have accrued.  Best dump them now and move on.

Daily Stand-ups

Daily stand-ups should achieve the following goals:

• share commitment
• communicate daily status, progress, and plans to the team and any observers
• identify obstacles so that the team can take steps to remove them
• set direction and focus
• build a team

It's Not Just Standing Up: Patterns for Daily Stand-up Meetings by Jason Yip

Notes for another day/week/month.  Certainly worth returning to.

Dave Thomas

A helicopter has four main controls: foot pedals, collective pitch lever, cyclic, and throttle. The foot pedals control the tail rotor. With the foot pedals you can counteract the torque of the main blade and, basically, point the nose where you want the helicopter to go. The collective pitch lever, which you hold in your left hand, controls the pitch on the rotor blades. This lets you control the amount of lift the blades generate. The cyclic, which you hold in your right hand, can tip one section of the blade. Move the cyclic, and the helicopter moves in the corresponding direction. The throttle sits at the end of the pitch lever.

It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you're constantly dancing on all the controls to keep the helicopter stable.

That's kind of similar to code. We've all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back—like that Whack-a-Mole game—and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you'll always get that kind of distributed bug fixing.

The funny thing about the helicopter story is that I'm not a helicopter pilot. When I wrote the helicopter story, I wanted to make sure it was accurate. I knew of a USENET group on helicopters, so I posted the helicopter story saying, "This is what I'm intending to write about how helicopter controls work. Is it correct? A helicopter pilot emailed me and said, "I read what you wrote about controlling helicopters. I didn't sleep all night."

-- Dave Thomas in Orthogonality and the Dry Principle

Games and Work

Must not distract myself, must do work...

Must not read or browse the online archive of the first 100 issues of Computer Gaming World magazine.

No no no.

Apple Down

With the final onset of autumnal weather we ventured out (delayed I admit) and braved the rain and Glastonburyesque festival mud to sit in a  straw-bale-filled marquee sipping mulled cider and watching the Mountain Firework Company (who I still adore). 

Long live apple festivals.

Down with then having to go do work in a cold office looking out into the dark.

Einstein

"If what is seen and experienced is portrayed in the language of logic then it is science. If it is communicated through forms whose connections are not accessible to the conscious mind but are recognized intuitively it is art."

-- Albert Einstein (Menschen, January 1921)

Rabbit Birthday

    Happy Nabaztag Day!  We all love wifi bunnies.

Nabaztag

So today I went to set up my new Nabaztag at the university. 

Sadly it is still not yet functional as the roaming network currently does not like bunnies. 

Fortunately, however, we may yet be able to bypass this as the nabaztag now constitutes a genuine research project - my officemate was so sold on it it may be used to investigate affect in online-community language learning. 

Long live feedback devices.

Squiz

Tufty's goal? To bring human civilation down and enslave its survivors in a hopeless cycle of harvesting delicious nuts for chitterbox consumption. The purpose of this page is to display the insideous propaganda tools and information Tufty used to brainwash and mislead his victims with the false promises of squirrel world domination.

Tufty, and his propoganda, hurts my head. 

It may be nap time - thank goodness I have a giant furry cushion and a nice view out of my office window.

Hmm, while I don't mind the beautiful woodpecker being part of the view, I wish that squirrel was not looking at me like that right now...