I guess that's why they call it eXtreme Programming.
The problems with refactoring code almost always seem to outweigh the benefits. There's not enough time in the plan, it works fine as it is, we'd need to completely regression test it, etc. etc. The problems (or excuses) are well versed and easy to reel off whenever the question of a major code refactor comes up.
The benefits are less obvious; more testable code and easier maintenance are the usual candidates, and they sound like small change in the face of all the problems mentioned before.
The thing is, while the "problems" are a one time hit, the benefits multiply every time you touch the code. As do the downsides of not refactoring! Every time you go back to that bit of code and change it, you'll have to do a bit more work than if you'd refactored it before. On top of that, every new change probably makes the refactoring case even stronger, until eventually, it can't be put off any longer and the refactoring work finally gets done. Only now, the code has more to it so the refactoring takes longer, which added to that the extra cost of each change up to that point, means the cost of not refactoring has suddenly become significant!
If we'd refactored up front, then subsequent changes to the code might have been easier, quicker, and we might also have a suite of unit tests that could provide us with a level of confidence in our changes that we previously didn't have. Suddenly the problems of yesterday don't outweigh the benefits at all.
So it's true, there really never is a good time to refactor, so don't delay, cut your losses and get it done now.
Thursday, 14 June 2012
Wednesday, 13 June 2012
Big Picture
In life, it's easy to get caught up in the here and now lose sight of where you're going. Before you know it, a small setback can stop you in your tracks and you're left rueing what might have been.
It pays to raise your head once in a while, look around, and check you're on the right path. It gives you a chance to self assess; are you missing a trick? will you regret buying that new car?
Managing complex software deliveries presents similar challenges. The focus is often to get your head down and focus on what you and your team need to produce to succeed. It's easy to assume that once you're done, you'll put your work together with that from the rest of the team and then that's it, you're done. A bit of integration maybe, but by and large, that's it.
If you don't stay tuned to those around you though, you might miss that one part of the team is struggling to deliver and has been forced into a slightly different design path. Now, suddenly when you come to integrate your work, you've done one thing, but the rest of the team's done something else. You take time to assess and realise that you need to rework much of your component for the project to be successful. This add to both time and budget, and the team is seen to be delivering late.
Despite how ridiculous this situation sounds, it probably happens more than you think. Fortunately, SCRUM actively works to avoid situations like this in several ways:
The daily scrum serves to synchronise the efforts of the team and make sure everyone's pushing in the same direction. Each team member reports on what they've done since the last scrum, what they plan to do until the next, and what is potentially blocking them from making progress. This makes sure that everyone knows what the rest of the team is doing, highlights problems as early as possible, and prompts conversation between team members to help each other through any issues they're having.
Organising work into sprints helps keep focus for short periods, but promotes regular inspection and assessment of where the project's going and what's being delivered. Each sprint delivers a potentially shippable version of the product, giving customers and product owners the best possible information to be able to give feedback and prioritise features.
Maintaining a prioritised product backlog ensures that the team is always focussed on the most important things for the customer. The product backlog is the customer's medium to communicate what they want to see in the product, and what they deem to be most important. The team then uses this to guide the work they assign to their sprints at the sprint planning meeting. Since the customer is present at this meeting, it's a great opportunity for the team to ask questions, get clarification and understand the customer's needs.
SCRUM is not a methodology for writing software, it's a toolset and framework that helps teams be successful. SCRUM's philosophy is firmly rooted in the view that projects should be transparent to their stakeholders, inspect regularly and adapt as required. What this means at the ground level, is that teams always have the confidence that they're delivering value, and are always getting feedback from each other and the customer at every stage of the process.
At the very least it's fair to say, that with SCRUM you're unlikely to wake up 6 months down the line, behind schedule and scrambling to implement critical features, having conversations with customers about how "the software's great, but to really be valuable, I need it to do this..."
It pays to raise your head once in a while, look around, and check you're on the right path. It gives you a chance to self assess; are you missing a trick? will you regret buying that new car?
Managing complex software deliveries presents similar challenges. The focus is often to get your head down and focus on what you and your team need to produce to succeed. It's easy to assume that once you're done, you'll put your work together with that from the rest of the team and then that's it, you're done. A bit of integration maybe, but by and large, that's it.
If you don't stay tuned to those around you though, you might miss that one part of the team is struggling to deliver and has been forced into a slightly different design path. Now, suddenly when you come to integrate your work, you've done one thing, but the rest of the team's done something else. You take time to assess and realise that you need to rework much of your component for the project to be successful. This add to both time and budget, and the team is seen to be delivering late.
Despite how ridiculous this situation sounds, it probably happens more than you think. Fortunately, SCRUM actively works to avoid situations like this in several ways:
The daily scrum serves to synchronise the efforts of the team and make sure everyone's pushing in the same direction. Each team member reports on what they've done since the last scrum, what they plan to do until the next, and what is potentially blocking them from making progress. This makes sure that everyone knows what the rest of the team is doing, highlights problems as early as possible, and prompts conversation between team members to help each other through any issues they're having.
Organising work into sprints helps keep focus for short periods, but promotes regular inspection and assessment of where the project's going and what's being delivered. Each sprint delivers a potentially shippable version of the product, giving customers and product owners the best possible information to be able to give feedback and prioritise features.
Maintaining a prioritised product backlog ensures that the team is always focussed on the most important things for the customer. The product backlog is the customer's medium to communicate what they want to see in the product, and what they deem to be most important. The team then uses this to guide the work they assign to their sprints at the sprint planning meeting. Since the customer is present at this meeting, it's a great opportunity for the team to ask questions, get clarification and understand the customer's needs.
SCRUM is not a methodology for writing software, it's a toolset and framework that helps teams be successful. SCRUM's philosophy is firmly rooted in the view that projects should be transparent to their stakeholders, inspect regularly and adapt as required. What this means at the ground level, is that teams always have the confidence that they're delivering value, and are always getting feedback from each other and the customer at every stage of the process.
At the very least it's fair to say, that with SCRUM you're unlikely to wake up 6 months down the line, behind schedule and scrambling to implement critical features, having conversations with customers about how "the software's great, but to really be valuable, I need it to do this..."
Subscribe to:
Posts (Atom)