thekua.com@work

The split in the Scrum community with Ken Schwaber going independent of the Scrum Alliance sees Scrum.org announce the Professional Scrum Developer program.

An interesting development indeed. There’s also now a competing certification for the Professional Scrum Master instead of the Certified Scrum Master. I’m sure this is going to be confusing for everyone. (I wonder if that means Certified Scrum Masters are then implied as Unprofessional as a result?)

Comments(4)

Andy wrote a great blog post trying to relate Shu Ha Ri to the Dreyfus Model of Skills Acquisition. When I posted my thoughts, he suggested I blog about my story, so here it is.

In it’s simplest form, Shu -> Ha -> Ri roughly translates to Follow -> Detach -> Transcend. When I think back to the days when I studied Aikido (where I believe these concepts originate), I considered Shu Ha Ri as the flow of energy, or where you focus the majority of your efforts.

Photo of energy taken from HocusFocusClick’s Flickr stream under the creative commons licence

A Shu person, for example, focuses their energy on simply executing a very basic move. They repeat the kata, over and over, with the weight of their conscious mostly on thinking, “I move my arm up to block”.

The Ha person, no longer follows the rote kata, “detaching” from the original conscious thought, now focused on its application. They spend their time thinking, “An arm is coming my way, I better block”.

The Ri person is certainly spectacular to witness with energy flowing from move to move, something the dojo sensei demonstrated during a yearly open house. During this event, lasting a good twenty minutes, five black belt students attacked the sensei from all sides. They attacked with their hands and a small assortment of weapons. The sensei defended by turning, locking and throwing each student back in return. What I still remember vividly was comparing the black belts, completely drenched to the skin in sweat, to the sensei, who barely showed any signs of sweat.

I see this same flow of energy and focus of effort when watching people learn development skills. At one end of the spectrum, the Shu developer spends an enormous effort thinking about how to execute a particular practice. At the other end of the spectrum, the right practices occur and great quality code (and tests) appear.

Comments(1)

One of the biggest differentiators between the users who prefer IntelliJ over Eclipse is often their dedication to learning keyboard shortcuts. The user-conscious designers of IntelliJ make as much as they can consistent, something much more difficult for Eclipse, who is dependent on a community for plugin development without any process for reviewing how well they all fit together.

On my very first ThoughtWorks project, I remember my pair commenting about how I should learn all the keyboard shortcuts for IntelliJ. Learning keyboard shortcuts is less about churning out great amounts of code, and much more about avoiding interrupting your flow. Simple actions, such as reaching for mouse have potential to break your flow. Jetbrains make it easy to learn the keyboard shortcuts, even providing a printable cheat sheet so you can put them around your workspace as you learn them.

Having said all of this, here are some of the keyboard shortcuts I find myself using all the time for iPhone development:

• Switch to Header/Source File- ALT + CMD + UpArrow
• Open quickly – Shift + CMD + D. This is as close to Jump to Class/Method/Symbol that I could find so far. I haven’t worked out how to search using regular expressions yet.
• Go back/forward – ALT + CMD + LeftArrow/RightArrow. Moves back between files that you opened. Useful for cycling through a call stack
• Go(Run) – CMD + Enter. I’m currently using this to quickly see results as a spike my way through learning about Objective C and the APIs
• Open Console – SHIFT + CMD + R. Useful when debugging using log statements and looking at what’s going on.

I’ve also found application-wide standard keyboard shortcuts really helpful as well

• Cycle through different applications (XCode, Interface Builder) – CMD + TAB
• Cycle through different windows in the same application – CMD + ` or CMD + ~. These are all really useful because Apple applications have a tendency to open many many windows, not really ideal for keyboard use.
• Open help – SHIFT + CMD + ?. This is really useful when no keyboard shortcut is mapped, or you want to access a menu and can’t remember what it was. Once you have the Help dialogue open, start typing the name of the menu item. I’ve used this quite a lot to access the Refactor menu item which pops open another window.

Of course there are many more keyboard shortcuts. These are simply the ones that I’ve found I’m getting the most productivity. I wouldn’t say all of development can driven through the keyboard alone, but it’s a pretty good start for now. What are your favourite ones?

Comments(2)

Late last week, Andy Yates got me onto the whole Hello World application for the iPhone. Since then, I’ve been dabbling around a bit more trying to get my head around it. After having studied how people learn things using models such as Shu Ha Ri, the Dreyfus Model of Skills Acquisition, and Kolb’s learning cycle, it’s fascinating to try to understand how best to pick it up.

Here are some observations that I’ve made so far:

• There are many different dimensions to learning how to write an iPhone application. First, there is the fact that it’s written in Objective C, so you’re learning about the syntax and intricacies of a new language. Secondly, you are learning new development tools including XCode and Interface Builder. Thirdly you are learning about the libraries, documentation, and understanding how things fit together.
• I intentionally recognise myself as being at Shu level (in Shu Ha Ri) or a Novice (on the Dreyfus Model). This means that I want to have some quick wins, get stuff working and worry about how it all fits together in the next stage. I’ve found that repeating the same exercise (almost like a kata) has helped me understand how things relate to each other just that little bit more.
• Writing a journal helps. I intend on blogging about some things that I’m discovering. It might help one person out but it will sure help me articulate clearly my understanding (or lack of understanding) about the topics that I’m finding. When I don’t blog, I’ve got a little text file with snippets on what things I’ve discovered and what things still puzzle me. It’s helping me organise the random things that I’ve got.
• Interestingly, I’m less interested in following some of the practices I would if writing a production application. This means I’m not worrying too much about refactoring or testing until I get the basics down. I don’t want to confuse the concerns of exploration and learning with verifying the system works (which I can barely get going right now). When I am more confident in my knowledge, I’ll definitely spend more time thinking about these things.

Comments(4)

I upgraded to the latest version of Notepad++ (5.5) and noticed that I sometimes get some problems with a dialogue box that pops up, looking like the picture the right stating (Load Langs.xml failed!)

Having a quick look at the installation directory, it looks like a langs.xml file exists yet it has a 0KB size. I’m not sure what causes it yet (perhaps it’s if you kill the process mid-way using Task Manager) but all I did was take a copy of langs.model.xml and rename the copy as langs.xml. Fixes it all up!

Comments(12)

The less that something is run, the more likely it will be broken.

Comments(0)

A work colleague pointed me out to this fascinating article called, “The unspoken truth about managing geeks” that I think anyone working in IT needs to know about.

There are some great bites of information in there that I picked up including:

• Avoid laying blame on stereotypes and look at the system that drives out certain behaviours (such as those factors amplifying stereotypical behaviour)
• Geeks trust people who help get the job done. Geeks find ways to work around people who don’t.
• Unlike in almost every other area, it’s often not how you say something that matters, it’s what you say. Maybe it’s because of logic but geeks detect when things don’t quite add up.

I suggest you read everything in the article. I don’t necessarily think all of it is accurate at all of the same time but it’s well written and gives people insight into why geeks often behave as they do.

Comments(0)

It looks like the authors of the wonderfully simple Poster Add On have released a version that works with the latest release of Firefox (3.5.2). According to the ticket someone logged, the add on is still waiting to be approved, iTunes style here.

Comments(1)

I’m excited to announce that I will be running my workshop again, Climbing the Dreyfus Ladder of Agile Practices at the Agile 2009 conference in just over a week’s time. This is the same workshop that I hosted at XP2009 in Italy. In addition to this, my great colleague Alistair Jones and I will also be co-presenting an experience report, Top ten secret weapons for performance testing in an agile environment. Hope you can make it to one of these. I’m really excited to be sharing some lessons I’ve learned along the way.

I’m keeping a page from the session here.

Comments(1)

I’ve been working with a large scale legacy system (in the Michael Feathers’ sense). Strangely enough there are a small handful of tests, unfortunately most of them falling by the way side having not been added into an Continuous Integration process. Many of them no longer look relevant, others, unable to run without a specific person’s machine (due to configuration files or special databases). Others look like a mechanism for people to simply diagnose issues with plenty of tracing statements. All of this was an inevitable system without someone running all the tests all the time.

Any serious team serious about continuous integration will think hard about their development testing strategy, considering approaches that allow you to run tests all the time. The strategy needs to consider a good way of preventing side effects from other tests (global state, global configuration, or left over state in external resources) balancing out speed with good quality feedback. Staggering build processes into smaller chunks, such as using build pipelines are a great way of achieving this.

Please don’t let leave your tests to die a sad and lonely death. It will take discipline and effort to keep them running yet the results will often pay back for themselves very quickly on any system with a reasonable lifespan.

Comments(2)