Lean Thinking

Tuesday, 24 July 2018 15:41

The Boy Scout Principle

Published in Agile

Last time we looked at refactoring. How real refactoring isn't re-writing big chunks of legacy code, it's cleaning as you go. Making sure the code you write now is clean. But what do you do about those big lumps of legacy? They weren't written with "clean" in mind, they were written with "hack it together to meet the date" in mind instead. It's messy and it's slowing you down. What do we do about it?

Well, we need to refactor it. But how, if we can't spend the whole sprint rewriting a big chunk of it? We need to stop thinking big - think small instead. Use the Boy Scout Principle - leave the camp ground cleaner than when you found it. When scouts leave a camp ground, they spend a few minutes cleaning up. Not just their rubbish but anything else they can find left by previous campers. And crucially, they don't try to clean up the whole forest, or even the whole camp-site - that would take weeks - they just clean up the area they were using.

Tuesday, 10 July 2018 22:42

Clean = Fast

Published in Agile

Whenever I mention refactoring in an organisation, I usually get the same response - "Yes, we know it's important, but we don't have time. We need to move fast. We can't afford to go back and keep tweaking things, we have to keep moving forwards". On the surface that's a reasonable sounding argument. It doesn't matter whether your organisation is big or small, established or startup, the imperative is to move fast. Get things done. Those customers won't wait, you either give them what they want now or someone else will. In an environment like that, who has time for refactoring?

I'd like to challenge that thinking. Not the bit about having to move fast, that's a given these days. No, the bit I want to challenge is the bit about refactoring being incompatible with being fast. To me, refactoring is not an impediment to being fast, it's an enabler. I think the view that refactoring slows you down stems from a serious misinterpretation of what refactoring is.

Tuesday, 15 May 2018 12:28

The Rebuild Trap

Published in Agile

Another post in my series about common traps that organisations can get themselves into. This week we will look at a really common one. I think I have seen this in one form or another at every organisation I have ever worked for. It's really easy to get into. Once you are in it, it's really hard to get out of. But fortunately, once you know what you are looking for it is really easy to avoid. It's the rebuild trap.

It works this way - the product or process you are working in is becoming old and inefficient. The code base is old and riddled with tech debt. Technologies have gone out of date. It's becoming slower and slower (and more and more expensive) to add new features or other changes. Finally the organisation throws up its hands and announces that the system will be re-built. Everyone cheers. Out with the old, in with the new. A team is stood up. Everyone fights to be on the sexy new rebuild team rather than the boring old legacy maintenance team. Work begins and...never ends. The new system never gets delivered. The old one never gets replaced. Large amounts of money are spent with no result. The other possible outcome is that the new system eventually gets delivered, very late and with vastly less functionality than the one it replaces. What went wrong?

Calendar

« November 2018 »
Mon Tue Wed Thu Fri Sat Sun
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30