As a former CTO/architect who believed he WAS being assertive enough, I’ve come to believe that assertiveness is really only half of the equation here. Programming is, in all too many cases, the process of innovation by schedule - you will create a completely novel solution by the 1st of December, regardless of whether or not such a solution has ever been completed before, whether you have the technical skills in-house or available by contract to produce it, or whether or not not you even have all of the (non-programming) resources (such as critical data contracts) that are necessary by then.
Such requirements are frequently driven by factors that have nothing to do with the technical issues involved: the client has only so much money involved, and in order to get sale, the sales team have promised far more than the programming team can deliver on, as one example, or the managers need to have a functional application by a given date because only if they have it will they be able to meet a funding deadline by the investors. One client of mine in particular refused to even look at wireframes of a web-based application until a week before the product was supposed to be finished, then panicked when they realized that what they had loosely set out in their requirements were in fact being implemented according to what was written, not what was desired.
What many programmers don’t realize is that what, to them, is a straightforward process is to most of those A-type personalities little short of magic. The typical marketing or sales VP can’t understand what’s going on at the technical level beyond what they are told, and to add insult to injury, many senior marketing or sales executives also believe that they do understand this, meaning that what gets sold to clients is typically not only not feasible within a given timeframe but not feasible within ANY given timeframe. Again a prime example of this in a company I worked for was a senior sales VP who nearly sold a number of clients on the fact that we could create generalized publishing solutions for any of their work that would scan existing content from hard copy sources and then generate, automagically, the properly formatted output in XML with full contextual support. Given that this remains one of the single hardest nuts to crack in publishing, this venture would have basically ended up committing every single programmer at the company to a life of perdition before they put in their resumes.
This also plays into another facet of the programmer personality. Young programmers (the ones most likely to end up bearing the brunt of these decisions) are eager to prove that they are capable of doing pretty much anything as much for the personal prestige as anything, so in general they will likely be the last to admit that what is being presented cannot be done BY them. Programmers can be as assertive as anyone when it comes to that alpha-geek competitiveness, but admitting that something can’t be done involves an embarassing loss of face (and quite possibly a loss of job) if some other programmer cuts them off and says that it can be done within the constraints provided, even if it’s just posturing.
A similar situation can arise through simple miscommunication - programmers tend to be far more exact in their definitions than non-programmers because they have to be … they are often the ones writing the definitions in the first place. Thus, when a non-techie manager (one who controls your paycheck) asks whether its possible to do something, what they are asking is whether its possible to do that something within the budget, time, and amorphous requirements that are floating around at the time, often with themselves having only a vague idea about what these are. The programmer, on the other hand, will parse this as - does the technology exist (or can it be created) to perform a given task, and then will generally answer in the affirmative because they know that most problems are ultimately soluble, given the right resources.
Finally (and related to this), when a manager is asking for an evaluation of a technology (up to and including a timeline) typically that manager is wanting a definitive answer - yes or no by this date- so that he can go back and report this back to his boss/investors/board.
The programmer on the other hand will most likely end up seeing most software projects as being distribution curves with varying degrees of deviancy from the norm, with a given date being that point which, given normal fault tolerances in estimates, can provide a probability of say 80% that the project will be completed by, with variances that may be as much as 100% of that estimate.
When the programmer goes back to the manager, the manager perceives this as equivocation, and typically reacts angrily to it (in my experience), often to the point of trying to get the programmer to nail down on a specific date. If the programmer is being honest, the date will not be acceptable to the manager, who is of course being pressured to get this project done under budget and in the time frame so outlined, who will in turn pressure the programmer to give earlier estimates.
Since those estimates are fuzzy at best anyway, the programmer is often then forced to compromise on an earlier date with a lower degree of confidence, and later becomes the one to bear the brunt of the fallout near the end of the project when it in fact DOES come in closer to the initial estimates (the manager typically escapes, of course - they can point to their programmers and say that the estimates they gave were off, and that’s what I based my estimates on).
The best tool that a programmer has to prevent this is personal email notes to themselves documenting every transaction, every request for estimates, and every change request. It takes some work from the actual day to day programming to document this, but typically in the long run it not only serves to keep the programmer on track but also provides material for an audit trail to show why such estimates were made in the first place. This is not to say that managers are malicious and determined to ruin the lives of programmers - most are just trying to get the job done themselves - but it can serve as a way of insuring that incompetent, grandstanding or malicious managers aren’t promoted up into higher levels of authority and can also make wrongful termination suits and breach of contract far easier to prove or disprove.
