And what does plumbing have to do with agile development?
In my spare time, I started this bathroom renovation project. Long story short, we are at the stage of life where we are taking care of children and grandparents. The sandwich generation, I think is what it’s called.
Anyway, we are converting an office, powder room and laundry room into a main level guest suite so visiting grandmothers don’t have to climb the stairs multiple times per day. We decided to tackle this project ourselves and the first step, after planning it out, was demolition.
One can learn a lot by taking something apart. As we peeled back the layers of cabinets, crown moulding, drywall, electrical, plumbing, studs, floors, etc., we were able to witness the history of the house. We saw wallpaper on top of paint on top of wall paper. You could date the house based on the style of wall paper.
Most importantly, we learned how professional building contractors install plumbing, electrical, and structural walls behind the skin of American drywall. Out of curiosity, I Googled how to do plumbing to see the science and compare what I found online with what I witnessed in my home.
Anyway, long story short, we discovered that the way builders installed the plumbing when the house was built could be improved. After demolishing the old plumbing and putting in new plumbing, we did it in a better, more efficient way.
In technical agile terms, we “refactored” the plumbing.
Next day I go into work and we have a discussion with a client about refactoring the code we did a few years ago. The client asked if this refactoring was considered within our warranty. The client wanted to know why they should have to pay for us to redo code we already did once.
Well, I guess we could debate about the contract and warranty. But, what I realize is that, particularly with agile, the first priority is to prototype an MVP. Make something that will work. Test it. Get users to test it. Get feedback. Then iterate. Along the way, particularly with user feedback, we discover better ways of doing things. We discover that some features might not be used or needed. We discover people using features in a way he hadn’t anticipated.
Over time and with use and with new information, it make sense to take things apart and redo them in a better, more efficient way.
So, should clients pay for refactoring? Well, personally, I believe that if we put an MVP together quickly and cost-effectively to prove or disprove a concept then that is value. Then, over time, if we find better ways to do something or improve the code to make it more secure and faster based on the evolving climate, then that is also added value. People will pay for value if they understand and appreciate that value.
So, my answer is yes. Refactoring is a value-added service that should be compensated.