The Blindfolded Ninja Model of Software Development

The ancient and respected team of Science Ninja is amazing. For centuries (or so it seems) they’ve protected the temple of Llabdum. The temple is old, with many places showing signs of previous attacks, or simply crumbling rock and weapons still in the skeletal hands of fallen enemies. Or maybe, you know, just lego bricks left lying about by younger Ninja-to-be.

People always marvel at the antics of the Ninja. As they practice moving between different parts of the temple, they put on blindfolds and go from one place on the defences to the other. Some places, they manage to walk in the exact rhythm needed to avoid the lego bricks on the floor, with running strides of the exact needed length, and that final jump at the end of the corridor. Some of the more experienced Ninja know how to cross the ancient garden, with its many treacherous walls, pits filled with blades, and snap-wires intended to trap unsuspecting intruders. They jump, flip, pirouette, land on their fingertips before doing a perfectly timed series of flip-flops through a line of moving stone wheels, ending up on the southern wall ready to defend the temple.

When a visiting warrior, who was sent with a team of eXPerienced soldiers, sees all this, he asks: isn’t that a little cumbersome? Wouldn’t you be able to move more quickly if you got rid of all that rubble? And why have traps inside your temple?

The Ninja scoffed at him. You obviously do not have our skills and experience, so you are not qualified to judge our defenses. The warrior, having just stepped into a particularly nasty piece of lego, winced, and suggested that he and his soldiers at least clear out the main corridor, so that they, in their untrained ways, could reach the two main walls quickly. And so it was done.

The soldiers picked up pieces of lego from all over the floor of the corridor. They found many, and some had to be very carefully extracted so as not to damage the ancient floor any further. They repaired the floor as well as possible, restoring the mosaic, with the picture becoming clearer every day. With the lego-bricks, they actually fortified a part of the southern wall that had been crumbling, but was now restored to a shining, if oddly multi-colored, unassailable wall.

At first, the Ninja still went through the corridor in their traditional pace, with irregular jumps and steps avoiding the now no longer existing hurdles. The next attack on the temple, though, the soldiers ran through the corridor at full speed, and were at the defenses before any of the Ninja. The shame was unbearable, and the Ninja got together to discuss changes to their customs. They talked with the visiting warrior, and had a look at the inner garden. They sectioned off one part (the pit with blades, I think it was), and started the work of making that part of their codebase accessible.

Don’t Refactor. Rebuild. Kinda.

I recently had the chance to speak at the wonderful Lean Agile Scotland conference. The conference had a very wide range of subjects being discussed on an amazingly high level: complexity theory, lean thinking, agile methods, and even technical practices!

I followed a great presentation by Steve Smith on how the popularity of feature branching strategies make Continuous Integration difficult to impossible. I couldn’t have asked for a better lead in for my own talk.

Which is about giving up and starting over. Kinda.

Learning environments

Why? Because, when you really get down to it, refactoring an old piece of junk, sorry, legacy code, is bloody difficult!

Sure, if you give me a few experienced XP guys, or ‘software craftsmen’, and let us at it, we’ll get it done. But I don’t usually have that luxury. And most organisations don’t.

When you have a team that is new to the agile development practices, like TDD, refactoring, clean code, etc. then learning that stuff in the context of a big ball of mud is really hard.

You see, when people start to learn about something like TDD, they do some exercises, read a book, maybe even get a training. They’ll see this kind of code:

Example code from Kent Beck's book: "Test Drive Developmen: By Example"

Example code from Kent Beck’s book: “Test Drive Development: By Example”

Then they get back to work, and are on their own again, and they’re confronted with something like this:

Code Sample from my post "Code Cleaning: A refactoring example in 50 easy steps"

Code Sample from my post “Code Cleaning: A refactoring example in 50 easy steps”

And then, when they say that TDD doesn’t work, or that agile won’t work in their ‘real world’ situation we say they didn’t try hard enough. In these circumstances it is very hard to succeed. 

So how can we deal with situations like this? As I mentioned above, an influx of experienced developers that know how to get a legacy system under control is wonderful, but not very likely. Developers that haven’t done that sort of thing before really will need time to gain the necessary skills, and that needs to be done in a more controlled, or controllable, environment. Like a new codebase, started from scratch.

Easy now, I understand your reluctance! Throwing away everything you’ve built and starting over is pretty much the reverse of the advice we normally give.

Let me explain using an example.

Contine reading

Agile 2015 Talk: Don’t Refactor. Rebuild. Kinda.

Monday, August 3, I had the opportunity to give a talk at the Agile Alliance’s Agile 2015 conference in Washington, D.C. My first conference in the US, and it was absolutely fantastic to be able to meet so many people I’d only interacted with on mailing lists and twitter. It was also a huge conference, with about 17 concurrent tracks and 2200 participants. I’m sure I’ve missed meeting as many people as I did manage to find in those masses. IMG_20150803_135914

Even with that many tracks, though, there were still plenty of people that showed up for my talk on Monday afternoon. So many that we actually had to turn people away. This is great, I’ve never been a fire hazard before. I was a bit worried beforehand. With my talk dealing with issues of refactoring, rebuild and legacy code,  it was a little unnerving to be programmed against Michael Feathers…

My talk is about how we have so much difficulty teaching well known and proven techniques from XP, such as TDD and ATDD, and some of the evolved ones like Continuous Delivery. And that the reason for that could be that these things are so much more difficult to do when working with legacy systems. Especially if you’re still learning the techniques! At the very least, it’s much more scary.

I then discuss, grounded in the example of a project at the VNU/Pergroep Online Services, how using an architectural approach such as the Strangler Pattern, combined with process rules from XP and Continuous Delivery, can allow even a team new to them to surprisingly quickly adopt these techniques and grow in proficiency along with their new code.

Rebuilding. Kinda.

Slides

The slides of my talk are available on slideshare, included below.

 

I’ll devote a separate post in a few weeks to give the full story I discuss here. In the mean time…

If you missed the talk, perhaps because you happened to be on a different continent, I’ll be reprising it next Wednesday at the ASAS Nights event, in Arnhem. I’d love to see you there!

I'm speaking at ASAS Nights 2 september

Everybody need somebody

On occasion, I like to listen to podcasts. Some of the most interesting can be those that are from outside of the software industry. This week I was listening to Robb Wolf’s podcast, where he hosted guest David Werner. Robb talks mostly about diet, metabolism and exercise, and this episode was focused on that last one. Both Robb and David are coaches. In the sports sense of the word: they own gyms, and teach people how to exercise both for general health and to improve performance in some sports endeavor.

Listening to people who are experts in their area is always a joy. Because learning by osmosis is fun. Because listening to people talk at a higher level of experience then you can helps you find out what is really important in an area (well, sometimes…). A joy. And, remarkably, it’s also a joy to find how people in completely different lines of work have found ways of working and thinking that so resemble things in my own area of work.

So it was nice to hear David Werner talking extensively about improving in small steps. About the danger (in physical training) of taking too big a step, and having related smaller goals that won’t over-strain you current capacity. And about how often people don’t do this, and try to do pull-ups while they’re not even able to do a proper push-up, damaging their shoulders in the process. The fact that I’m still recovering from my own shoulder injury due to over-straining has only marginal influence on that.

drop down and give my twenty! (well, if you can. Otherwise 3?)

drop down and give me twenty! (well, if you can. Otherwise 3?)

David went on to describe that based on that experience, he was building his new website in the same manner. He even mentioned that there was some Japanese word that is sometimes used for that. Kai-something?

Another piece of cross-industry wisdom is their discussion on how everybody, no matter how experienced, needs a coach. Robb joining David’s training helped him find areas where he could improve his fitness that he hadn’t found himself. I guess that the more of an expert you are in an area, the more expert your coach would need to be, but having an outside view of what your doing is the very best way to get better of what you do.

Everybody needs a coach

As a coach, of consultant, or whatever you want to call it, it’s sometimes hard to get this kind of feedback. That’s why initiatives such as Yves’ Pair Coaching, of one of the Agile Coach camps are very valuable. And why we like to go to all those conferences. But you can find opportunities in your everyday work as well, just by explicitly looking for it.