It almost sounds like you are advocating a style of code ownership where programmers shouldn't make changes to other's code without talking to them.
I realize the context of your article requires a coding example that is somewhat trivial to understand and pick apart by developers who have a "better way", but I also think it's a copout to claim that the programmers in your example are just refactoring code for the fun of it.
A lot of people are rightly fixating on the formatting "feature" of not padding 2-digit zip codes. If I was on that project I could easily see myself wanting to reuse the zip-code formatter and running into an issue where my use case requires the 2-digit zip codes to get padded.
On most projects a zip-code formatter shouldn't be such a big deal that it requires a meeting between programmers. If the original zip-code formatter had bizarro requirements then they should be made more explicit.
For some reason the article avoids the biggest mistake in the whole process. Why did the other programmers make changes without ensuring the test cases passed?
> It almost sounds like you are advocating a style of code ownership where programmers shouldn't make changes to other's code without talking to them.
Sure, we could say there should be more tests, or people should run them. We can say there should be issues filed before you refactor things. We can try to introduce all sorts of processes for avoiding mistakes. And we'd be right.
But it's also nice to talk to a human, even if just casually. I don't want to say "shouldn't X without Y" because then "shouldn't make changes to other's code without talking to them" is much the same thing as "shouldn't make changes without running existing tests" and "shouldn't check changes in without submitting tests that the code fixes."
Shoulds and shouldn'ts should always be secondary to talking.
> It almost sounds like you are advocating a style of code ownership where programmers shouldn't make changes to other's code without talking to them.
Talking to the person who wrote the code you want to change is always a good idea. It's not always possible (because the original coder has left the company or something), but if you have the opportunity, use it. You'll learn something.
I do this all the time. Sometimes the answer is: "You're probably right. Change it." and sometimes it's "It's like that because of good reasons X and Y, and we also use this in another project that needs it to do Z." This understanding is very valuable, and can save you a lot of time.
And the really great thing that happens is when someone says, "Yeah, that code is an ugly hack, and please fix it up, but don't forget good reasons X and Y and Z." Then you get to make it batter without regressing, add the proper tests, and document everything properly, all because you spoke to someone first. :-)
I realize the context of your article requires a coding example that is somewhat trivial to understand and pick apart by developers who have a "better way", but I also think it's a copout to claim that the programmers in your example are just refactoring code for the fun of it.
A lot of people are rightly fixating on the formatting "feature" of not padding 2-digit zip codes. If I was on that project I could easily see myself wanting to reuse the zip-code formatter and running into an issue where my use case requires the 2-digit zip codes to get padded.
On most projects a zip-code formatter shouldn't be such a big deal that it requires a meeting between programmers. If the original zip-code formatter had bizarro requirements then they should be made more explicit.
For some reason the article avoids the biggest mistake in the whole process. Why did the other programmers make changes without ensuring the test cases passed?