Lean Thinking

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?


« July 2018 »
Mon Tue Wed Thu Fri Sat Sun
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 31