>Senior developers know that wasting two days fighting would be better spent elsewhere.
I disagree. Sometimes, yes, but most of the time, no. Two days fighting can save years of maintenance costs (and I'm assuming productive fighting, not fighting for the sake of it). Ever developed on a not-well-thought out database model? No foreign keys? No consistent naming? Dates as varchar? You're stuck with it. It not only causes more defects in existing code, it makes enhancements harder and more prone to defects.
But it's hard to speak up on such things. It much easier, mentally, to just say screw it and write the bad code, especially if someone is non-confrontational by nature.
You are not stuck with those things. Converting dates or adding references or changing the customer model or even migrating to a different type of database are things you would normally do when you start scaling anyways.
The code doesn't have to be perfect aligned to some doctrine.
If you feel the need to fight back over a single private member variable delay some important release the reasoning must be better than one day in the future it, it will make development slightly harder. Refactoring is a good practice.
>are things you would normally do when you start scaling anyways.
It is (sometimes but rarely fundamentally different refactoring) but when a crappy schema has been built on for years, it is exponentially more difficult to refactor, especially a live system with multiple clients and uses. The best (and cheapest) medicine for that is to not inject crappy design in the first place. Sometimes you have to, but it should really taste bad.
>The code doesn't have to be perfect aligned to some doctrine.
If the doctrine is not putting crappy / hacky code in the code base if you can at all help it, I think that's a fairly standard doctrine.
>If you feel the need to fight back over a single private member variable delay some important release
I'm not sure if the article said the discussion would delay a release or that the release was important. All those absolutely do come into play though. If they were in play, you'd think the dev lead would have enough respect for his team to point that out.
I disagree. Sometimes, yes, but most of the time, no. Two days fighting can save years of maintenance costs (and I'm assuming productive fighting, not fighting for the sake of it). Ever developed on a not-well-thought out database model? No foreign keys? No consistent naming? Dates as varchar? You're stuck with it. It not only causes more defects in existing code, it makes enhancements harder and more prone to defects.
But it's hard to speak up on such things. It much easier, mentally, to just say screw it and write the bad code, especially if someone is non-confrontational by nature.