Last couple of weeks, a few things happened that made me think. First, I started building a prototype for a Java application in Grails using Eclipse. Second, I wrote some small tools for Mozaic Works in python using Eclipse or vim. Third, I am involved in a startup that uses PHP to develop a great game. Fourth, I had my first TDD in C++ workshop in Stockholm. And, not to forget, my laptop runs Ubuntu.
I compared my last weeks with who I was 7 years ago. For my entire developer live, I used Windows and Visual Studio. I switched from C++ to C# in the 2000s, because it was new and better for the kind of applications I was doing back then. I knew a lot of things about Linux. I played with some scripting languages and was starting to like them. But why bother more? (more…)
This is how I started my Wildcard Talk at XP Days Hamburg 2012. It was really fun doing the kata on legacy code techniques in front of a great audience, and many asked me if I wrote about these techniques somewhere. Well, I just had! (If you just want to see the video, scroll down, I just added it).
So, let’s start with the basics. What is legacy code?
I’ve recently commented on a conversation in the Agile Coaching group on LinkedIn. I’m reproducing my comment here because it relates with a misconception that I see often.
The question it started from was, in my words, “Is a training enough to change the way a department works?”. My answer is below.
One year ago, I had the chance to be invited to speak at the second edition of Agile Portugal. I had no idea back then, but my view on software architecture was about to change for good.
“We cannot finish this feature in time. We need to change too much code to do it”. Joe, the technical lead, was always direct and honest.
“What would help?” Bill, the manager, was not happy, but he trusts Joe. If he told him that’s a big problem, he’s certainly right.
“We need to refactor parts of the code”
“How long would that take?”
“I guess about two weeks.”
“Fine, let’s do it” Bill is still not happy, but what else can he do?
I’m sure you have seen this story happening again and again. Usually the team asks for a “refactoring sprint” or “refactoring period” to “cut some of the technical debt”. The manager and the customer has to choose to invest in refactoring or risk schedule variance.
What’s wrong with this story? The developers clearly have good intentions and the managers make the call. But is this the only choice?