Refactoring

An interesting situation came up at work recently. I was leading a team that was reviewing an application that was developed about 18 months ago. There were some concerns around performance and scalability. The real question was, did this program need to be re-factored? How do you decide if/when it's time for refactoring?

One of the principles behind the Manifesto for Agile Software Development is Simplicity:

Simplicity--the art of maximizing the amount of work not done--is essential

In other words, keep it simple unless there's a current requirement to make it more complex. Don't try to design for some possible future requirement, design for what you know today...for what features are in the current iteration or release.

I've had architects that have struggled with this idea. They would argue that you need to come up with a comprehensive design up front. However, if the requirements aren't known completely (and when are they at the start of a project?) doing a full design will be challenging. I've seen organizations get caught up in analysis paralysis and have trouble getting anything built.

The key is to plan to the appropriate level of detail. At the beginning of a project there are a lot of unknowns, so a detailed design isn't practical. Focus on a design to get you through the first iteration, or maybe the first few iterations that make up a release. Know when you need to refactor.

What can change to require code to need refactoring. I can think of a couple situations;

• Change in requirements - Everything changes. As business needs change and evolve, the programs to support that business need to change as well.
• Change in technology - What technology are you using today that you weren't a year or two ago? Look at how popular devices like tables and smart phones have changed the the way people work and interact.

So what does this mean? The need for refactoring will always be there. I often advice clients that it's better to get a first release of an application to production as quick as possible, even if it's not perfect. You will start receiving some business benefits and it will give you better ideas on how to improve it.

Lean Project Management: How to Apply Lean Thinking in Your Next Project

This Guest Post is from Ian Needs of KeyedIn Solutions

You’ve almost certainly already heard of The Lean Startup by Eric Ries, a book that crushed business preconceptions by promoting a radically minimalist approach to new ventures.

Have you thought about how the principles of leanness can be applied to your project management? You should!

It isn’t all about ‘failing fast’. Lean project management boosts productivity and ROI by streamlining your project to focus on the aspects that have the greatest impact on success.

What Lean Project Management Means for You

Lean project management is the adoption of lean thinking in all areas of a project, from initiation right through to closure.

The aim is to deliver maximum value with minimum waste. In other words, you maximise your return on investment by investing as little as possible, while balancing this with optimal value to your business.

Adding lean thinking to your project management armoury helps you reach completion on time and on budget with minimum effort. To get you started, here are a few Lean Startup catchphrases translated into PM-speak:

“Eliminate Uncertainty”

Evaluate continuously, both to help you keep your project on-track and to know when it’s time to switch tracks entirely. Project management is an on-going process, and evaluation and feedback are vital for process evolution.

“Work Smarter, Not Harder”

Ask yourself first whether this project should be planned. A project whose rationale is shaky may not be worth your business’ resources. Second, ask whether what your need is already available – there’s no point reinventing the wheel if a solution exists that meets your project’s needs. Third, look at what elements you can automate to reduce waste.

“Develop a Minimum Viable Product”

For you, that’s a minimum viable project. Pilot your project on a very small scale, then measure and learn as you execute. By the time you initiate a larger-scale iteration of the project, you’ll already have collected a lot of valuable data to help you optimise the process.

“Validated Learning”

Incorporate empirical experiments into your project to validate your theories and test your assumptions. You can’t rely on an idea for project optimisation until you’ve validated it through the build-measure-learn process.

“Build – Measure – Learn”

For a PM, it’s execute-measure-learn. Never miss an opportunity to collect relevant, actionable data that can help you to laser-focus your project. Make sure that your plans include means and methods for making the most of this data once you’ve gathered it, too!

“Standardise”

In your projects, consistency of information, decision-making and communication are vital to smooth execution. Make sure everyone’s on the same page when it comes to outputs, and don’t forget the importance of standardising reward, too. Project culture and morale play a big part in the Lean Startup mentality for success.

“Pivot”

Sometimes, you have to abandon Plan A. This can be a stressful realisation, but don’t cling to your initial plans if the time for a course change has come. Plan B (or C, or D, or E) will give you a new horizon rather than leaving you stuck in a failing project.

If your projects have felt a bit bloated lately, try applying some of these lean ideas to clear the path. We’d all love to hear how it works for you!

About the author: Ian Needs works as Marketing Manager at KeyedIn Solutions. Find out about their comprehensive project management software package here.