Although I agree with your idea in principle, there are only so many times you can just hack something on top before you start to wonder if the refactoring technique is actually the better way to go. You could just end up with a hacky system held together with sticky tape.
With forethought, you should have built your system originally with method C in mind. If he had done this at the beginning instead of just hacking it together then all this work after wouldn't have been needed!
1) Apply conscious planning and forethought. Some things are clearly going to be used a lot, some things might not. Use bolt-on hacks where appropriate, invest time for things you expect to be using forever.
2) When the longevity of the tool is not easy to pin down, test it out with a hack. Spend 1 day adding Stripe the hacky way, and keep a slushbucket of time budgeted for revisiting experimental hacks that look like they will last a while.
That's my general approach, anyway. Most of the time, a hack is good enough and anything more is a waste of time. The story is admittedly a little different for me though; for me, software is a tool to do my job- software is not my job.
I think I see it differently as we have just spent 3 years developing a CMS at our company and every decision has been a well thought out and concious one. We spent 3 weeks planning when we first conceived the plan.
We have only had to do 2 refactors in that time on 2 controls. That was more about understanding our customers needs more as we progressed rather than not enough planning though.
Previous to that I built a custom ecommerce site for a wholesale distributor. That whole process was more suited to a quick hack over a well thought out decision. That's why I say I agree in principle, so long as the project allows it.
Don't get suckered into premature optimization. If you're still small, bolting stripe on lets you accept money and get back to building the rest of the product. Sometime in the future it will make perfect sense to redo the entire payment system. Today is not that day.
Comments
Although I agree with your idea in principle, there are only so many times you can just hack something on top before you start to wonder if the refactoring technique is actually the better way to go. You could just end up with a hacky system held together with sticky tape.
With forethought, you should have built your system originally with method C in mind. If he had done this at the beginning instead of just hacking it together then all this work after wouldn't have been needed!
This is why you need to do two things:
1) Apply conscious planning and forethought. Some things are clearly going to be used a lot, some things might not. Use bolt-on hacks where appropriate, invest time for things you expect to be using forever.
2) When the longevity of the tool is not easy to pin down, test it out with a hack. Spend 1 day adding Stripe the hacky way, and keep a slushbucket of time budgeted for revisiting experimental hacks that look like they will last a while.
That's my general approach, anyway. Most of the time, a hack is good enough and anything more is a waste of time. The story is admittedly a little different for me though; for me, software is a tool to do my job- software is not my job.
I think I see it differently as we have just spent 3 years developing a CMS at our company and every decision has been a well thought out and concious one. We spent 3 weeks planning when we first conceived the plan.
We have only had to do 2 refactors in that time on 2 controls. That was more about understanding our customers needs more as we progressed rather than not enough planning though.
Previous to that I built a custom ecommerce site for a wholesale distributor. That whole process was more suited to a quick hack over a well thought out decision. That's why I say I agree in principle, so long as the project allows it.
Don't get suckered into premature optimization. If you're still small, bolting stripe on lets you accept money and get back to building the rest of the product. Sometime in the future it will make perfect sense to redo the entire payment system. Today is not that day.
You are right, I think I am being closed minded in how we plan to build software instead of revenue.
That's how I develop now to be fair and not how I would build a product if I were to build it for myself.