I’m with Mahesh. This made me think of all the times I’ve seen people (of various professions) apply the same patching mentality in other areas of their lives: maintaining their vehicles, their finances, etc. Some of it may be the American culture of immediate gratification. It is so much quicker (in the short term) to just patch things!
When I keep coming back to the same section of code, or having to fix the same problem in different sections of code again and again that is a flag to me that just screams refactor.
In fact, I like to hold off on gratuitous refactoring until I start seeing red flags like that going up. Then I take a look at the code and spend a couple of days making a new interface, testing the interface and implementing it in the code base.
I have done this before for newline conversion, with parent-child communication, and with string and buffer handling.
You will get a lot of push back from people saying that there is no time to do things right. “We are way too busy carrying buckets of water to unroll the fire hose.” People like to look busy, they like to miss deadlines because it makes them look important. People that just calmly do the work on time never get any attention. But people who had to heroically battle a deadline despite having to patch the code in 1000 places in a 24/7 battle around the clock and get the code out just a week behind schedule look like heros.
Sad, but true.
hmm. sounds a bit,err, odd.
surely you write code to fix the geometry ? ie within a threshold weld vertices to near edges of adjacent polys, even if it involved basically retesselating the level, it’d still end up more friendly for the ps1 cache and vertex data was prolly texture data anyways.
It seems my job description should be Patch Developer. It annoys the hell out of me that my employer never allows the time to do something right and forces me to do something right NOW.
Ah, the ‘complete rewrite’ of the ‘crappy legacy code’ that just so happens to be the foundation of the company’s main source of income.
Been there, done that twice - in two separate companies.
First one: lasted 12 months - started with 18 engineers working on the rewrite. 12 months later I was the only one left - everyone else had been pulled back to do maintenance on the legacy code. As each engineer got pulled from the rewrite project it’s ETA sprinted further away into the future until it became obvious that it was never going to make it. To do certain rewrites you really need a company with a lot of spare cash that can afford to keep a maintenance team and a separate rewrite team going in parallel - sharing resources across both will never cut it.
Second one: lasted about 6 months - surprisingly not much actual code written as I spent most of the time in meetings while BAs, internal users and management argued about ‘what to build’ (hence no coding took place). The real problem there was one of the managers had a solution in his head from day one - outsourcing to a third party tool. When it became clear the tool option would cost around $500K there became an uneasy stalemate. I proposed a different approach: a piecemeal, module by module migration of the existing crap code to ‘refactored good code’ - a solution which would allow ROI with every iteration of the process but that was way to logical and the least expensive option so of course that was never going to fly =)
Actually the real problem in the second case above was that the legacy stuff wasn’t documented anywhere. Over many, many years hundreds of business rules had been implemented in the code but never documented anywhere. To rewrite it from scratch presented enormous risk - how would you know if you’ve implemented all the subtle, undocumented business rules in the new code?
and of course this project suffered from the ‘flavor of the month’ language syndrome and so its different modules were written in C, Java, shell script, Python, Visual Basic (used to write a very dodgy windows app) and some parts even suffered the misfortune of being written in some now unsupported 3GL… what a mess!
Counterexample: Evolution. Nothing but patches. Ever.
SteveC
True, but one hell of a lot of testing, continuous integration/rejection, no broken builds by definition, production system core unaffected by huge deviations from statistical mean, no apparent target output either.
There’s something to say about crappy programmers, but there’s something else to say about crappy programming languages.
Classic examples of am amateur approach to software; dive in head-first into unknown shallow waters.
As programmers we always want to work in a greenfield environment - writing completely new code, a chance to ‘do it right’… but as most programmers are typically optimists they completely underestimate the time it will take to get a system that has the same feature set and caters for all the forgotten ‘knarky’ use cases that the current legacy code handles.
So unless you work for a Microsoft or Google with deep pockets then the funding for a complete rewrite will typically evaporate before you’re 75% through the rewrite project.
Isn’t this the exact problem that we’re paid to solve? Don’t all programming problems basically fall under this umbrella? Aside from the most trivial bugs, every bug puts you in the “rewrite or patch” dilemma.
There really aren’t any hard or fast rules. Sometimes you have to go total rewrite, sometimes you gotta patch, but in the end, its having the experience, intelligence and sometimes intestinal fortitude to make that decision that separates the mediocre programmers from the great ones.
As an aside, I have a new spy name thanks to recaptcha. I will now be called Kartch Brosnan.
The patch is quite cute. I think I am going to feed him and rub his belly.
I proposed a different approach: a piecemeal, module by module migration of the existing crap code to ‘refactored good code’ - a solution which would allow ROI with every iteration of the process but that was way to logical and the least expensive option so of course that was never going to fly.
As expected the Test-Driven-Flagellates all come moaning out of the wood-work. And I tend to agree 100% with them - in the places where the theories ACTUALLY apply. Have you ever inherited a web application where the CSS has looked and acted like a house of cards? Just one small change to the style of the left menu? Please sir, can I have some more [time, much, much more time]? Ho hum, no manner of automated testing will fix this. Oh … but that’s just the domain of those scum eating web-developers and front-end monkeys ain’t it. If you have the chance, always rewrite the bastard.
Having recently worked on a project that could be described as a major rewrite of some code that had hundreds of unit tests, and where my testing strategy was “get all unit tests working, and then try a few million logged production examples,” I’d have to describe the belief that all you need to do is make sure the unit tests work as charmingly naive. Sure, your unit tests may have made sure that features A, B, and C all work independently. But did they cover the case where you had zero instances of feature A, three or more instances of feature B, and at least one instance of feature C (to cite the triggering condition for one of the production example behavior differences I found)? That’s expecting a lot from a unit test suite.
My first run of the production cases, after achieving “all unit tests pass,” turned up around 10% behavior difference/failures. The production cases were just a lot more complex than most of the existing unit tests. So yea for unit tests, but don’t think that is sufficient when trying to replicate complex code.
That dog is cute…my dog patches is one hell of an ugly mongrel.
I agree, the dog is cute. Looks one I had a when I was younger. Kudos on your blog post.
As with anything else, it’s a tradeoff. There are times when it makes sense to patch, times when it makes sense to rewrite, and times when it’s not clear. Are you going to do a rewrite for some minor “oops” bug that you could patch in 5 minutes? Obviously not – that’s a clear “patch” case. Are you going to patch when you are told to make your native app run on the web instead? Obviously not – that’s a clear “rewrite” case.
More generally, if the time to implement your current stack of changes without a rewrite is greater than the time to do a rewrite+current changes, then obviously you should rewrite. If you don’t have any ideas for architectural changes, but just have a local change that needs to be made, then obviously, you should patch. In between is a continuum of cases where you (or your manager) needs to make an educated decision based on level of effort, a guess on future requirements, and business constraints. If a patch will take a day and a rewrite will take two weeks, will the future labor saved by the rewrite justify a rewrite, and if yes, will the customer tolerate the delay and labor charge caused by the rewrite? If the answer to either above question is “no”, it’s patch time. This is certainly not a trivial decision.
If a patch will take a day and a rewrite will take two weeks, will the future labor saved by the rewrite justify a rewrite, and if yes, will the customer tolerate the delay and labor charge caused by the rewrite?