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 essentialIn 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.
2 comments:
I like the idea of not detailing solutions today for requirements you do not know yet. It is a waste!
I have been struggling (as in "I am behind my work") designing something I do not fully understand (as in "I need more details to accomplish what I had been trying to do").
It would have been better to deliver, two weeks ago, a high level model of the solution to the problem as I understood it. This would have highlighted my lack of available details, the waste of trying to detail the impossible, and the need to elicit requirements.
Thank you for the post.
I really liked this article on Keeping it Simple and Refactoring as time goes on.
The power of a product is in seeing it working. When people see a working product/software, and play around with it, they come up with more ideas, requirements, features.
Without the first working product available, the the users/sponsors/product owners may be able to visualize the entire product and provide detailed requirements. However, the time it will take to develop the entire product will counter the agility and ability to adapt and respond to the rapildy changing business and user models.
It is well said - Response to environment and refactoring can be done to handle changed requirements, user base, technology changes. The idea is to get the product released first and then add more and more.
It is similar to a a kid learning to walk. Baby steps. First step is to teach the kid to stand, then walk - first with support, then without support, one step at a time. The amazing confidence/happiness/results when the kid takes first steps cannot be matched with trying to have the kid run from the moment one plans to have the kid standup.
One never sets up an entire project to see a kid running from the very beginning.
Very nice topic on Refactoring. Thank you for the post. Regards, Deepti
Post a Comment