Note to self: Never go into a specification and design meeting saying “This should be fairly straightforward”, because it won’t be.

Adding “at the risk of jinxing it” will not reduce the risk of jinxing it.

Suits should stick to business requirements IMHO. It's when they get involved in programming that everything goes to he11 in a bucket. Then again, it's just as bad the other way around: developers telling execs they have to change the way they do business to suit (no pun intended) the program's design.

business req --> program spec --> prototype (repeat when necessary)

There's nothing worse than getting half way through a project just to have the requirements change on you. And guess whose fault it's going to be when you miss the deadline?

So true.

Additionally, in my case, I have had to deal with suits within the IT function also. What I mean is people from other domains in IT with and "I too did some file desigh earlier in my career" approach who impose their design due to seniority or proximity to the boss man.

It brings to mind something that happended early in my career. At that time we had two "finacial years". First a calander year to suit our foreign collaborator, and second an April to March year to suit the government requirements in India. A senior man imposed a file design where the months became columns in a table (twelve colums) instead of separate rows. We would first create a monthly tape and then had to separately merge this monthly tape with the appropriate YTD tapes.

It turned that this "suit" had worked in the reporting department of a data service company.

End