I had to backtrack on some code earlier today, owing to two design decisions shrouded in the mists of project history (i.e. pre-dating my watch). (The fact that one of these was both mind-blowingly stooopid and the handiwork of a self-proclaimed database guru didn't sweeten my temper.)
But one thing that I was certainly not including in the project scope was any change to the underlying database structure. And it had to do less with how things were supposed to be done than the realities of client relations. See, when your management has stooped the the level of even trying to dodge paying the base subscription fee, you can't can't consider yourself a "trophy client" anymore. Which means no more meet-n-greet trips out to your facilities on our dime. No more starting projects before the work authorization is even signed. And certainly no more freebie work, whether to humor you or enhance the infrastructure for the long term. To belabor the point, replacing relationships with transactions has consequences--and some of them I have absolutely no say in.
And I hate-Hate-HATE that! It affects the people who have to use this software day in and day out. People who are too contientious (and, frankly, just too darned decent) to deserve anything but top-drawer service. You can't even make the argument that Accounting doesn't have a line-item for such things. Intangibles such as "goodwill" and "brand equity" are certainly a factor whenever businesses are purchased.
But apart from that, I'm annoyed to discover yet another deficiency in my programmer education, which neglected to mention the impact of the client relationship on the software life cycle. And I think it brings home the point that when you pretend that no value exists outside of the bottom line, you lose more than you could ever possibly gain.
