Hector_McG
Of course, it is not always possible to avoid over-committing as sometimes the business calls for it.
Well that sounds like lazy acceptance of a bad situation for your team.
No mention of fighting for better terms for the team. If the business calls for over-committing you team, you or someone else in management have failed. Such a commitment may be indeed be unavoidable in that situation, but your job as a manager is to fight for your team to be additionally compensated for such an over-commitment.
You missed the huge, rending claws. Or is that just me?
That puts a whole new slant on the phrase “Don’t make a liar out of me.”
Is having a consistent domain language across the board important? Yes, obviously it’s a huge benefit in communication and in maintainability.
Is not following that convention, in and of itself, a huge problem? Probably not, so long as the primary parties understand the differences between separate aspects (such as the database using a different word order), although the documentation needs to explain this.
Is not being able to get an agreement on a consistent domain language that everyone will follow a problem for development? Yes. Huge. Crippling. It reeks of poor, indecisive management at the top project level, and petty interdepartmental squabbling all the way down. It’s a huge red flag as to a company’s ability to deliver. It’s not that difficult a thing to get agreement on or to enforce, as it’s entirely visible. If a project can’t do that, it’s not going to be able to do the things that are actually difficult.
Dennis Healy would be proud.
Program in assembly, 40 columns is plenty. You just need an awful lot of rows.
Round about the same time advances in genetic engineering allows us to freely mix avian and porcine DNA in viable hybrids.