I had a job working for a large Canadian company several years ago. Coming in, I was told that the specs were difficult, the tech had to be nailed, and they ha

I had a job working for a large Canadian company several years ago. Coming in, I was told that the specs were difficult, the tech had to be nailed, and they had already tried and failed. I took a week getting used to the customer, stack, and team. Digging through what they had? They needed two lines of code. It was the same exact situation. That was one of the more difficult consulting assignments I had. It took me quite a while to gently get the lead architect on-board. I had to position it so it looked like his idea. If I would have pushed hard, he would have pushed back...perhaps getting rid of me and hiring more of a team player. I've seen this a lot, in a lot of teams, and I think it has its roots in OO/Platonism, although it happens all over. I think the key things most of these teams are missing is that all structure is derivative. That is, there's not a line of code that's in your app that isn't in there for a reason. You're either really careful about that reason....or you add stuff because it looks good or you might need it someday, you can "imagine" how it might be helpful, the guy sitting next to you said you had to have it, and so on.