Software engineering is largely the art of balancing competing trade-offs. It's impossible to optimize every factor (features, speed, ease of use, ease of training, ease of future software change, money, etc.) One must try to satisfy the varying needs of the customer using limited resources and time. Not only must all these options be weighed and considered, but the customer needs to be kept knowledgeable about the various trade-offs even though they are not software experts. Thus, communications about tradeoffs is also important. Rules that say "always do X" are the naive approach. You do X because it's better than the alternatives and because you can describe why it's better in a practical sense, not out of habit or ArgumentFromAuthority. 

Yeah, there's a formalized mechanism for doing that -- QualityFunctionDeployment. The idea is to have the customer make these tradeoff decisions by assigning a relative value to all the important aspects of the product ''in relation'' to everything else. All of the characteristics are put into a list with the total value of their priority set to some number, say, 100. Each characteristic is assigned a value, but the total of all these values must exactly equal 100.

So if the customer wants more speed then he gets fewer features. If he wants faster upgrades then he spends more money, YaddaYaddaYadda. It makes for a fairly easy way to deal with the customer's expectations.

 Characteristics:
* more speed
* more features
* faster upgrades
* lower cost

[Isn't this list redundant with the one below? Perhaps they can be factored together.]

Of course, there will be plenty of discussion on how to measure whether some characteristic's value is rated too high or too low, but at least you have a place to begin talking about these things in terms that are customer domain specific and relative to each other. It puts the emphasis on the customer making his own decisions about how his product is going to end up working.

''Unfortunately, many managers think they are "above" such formal techniques and make excuses to avoid them ("screw that liberal arts bullshit"). A more successful approach may be to ask them to rank feature requests from highest to lowest. It has problems, such as not factoring in effort or cost to deliver such a feature, but it's better than having no idea how to allocate resources for requests. To deal with feature cost, one can point out cases where multiple medium-ranked features can be delivered in place of one higher-ranked one. -t''

Well, then, these are the kinds of managers you can do without. Sometimes a firm needs to make a painful decision to replace a long-time and otherwise valuable member of the management team if that member stands in the way of progress. I was at Motorola in the mid-80's when they kicked the VP of Semiconductor Products Sector because he refused to go along with the Participative Management Program as it had been mandated from Schaumburg. Too bad, said the crowd. Good riddance to bad rubbish, said the Crystal Tower (corporate office). If you can't get professionals to act professionally then dump 'em. -- MartySchrader

''The world is full of dumbshits and PointyHairedBosses (HumansSuck), but a lowly architect or project manager doesn't have the power to remove them. Under the best of circumstances, one can pick and choose their projects to avoid dumbshit managers, but that doesn't scale well to the majority of software IT workers. "Should" and "can" can't reach each other. Similarly everyone wants to marry the prettiest girl/mate, but there are only so many beauties to go around. The work world is largely a social institution, and human sociology is often illogical and irrational. Living and working with dumbshits is part of the "art of compromise".''

Perhaps so, but there is a sure-fire way of dealing with dumbshits -- '''the document.''' Daily logs, weekly reports, quarterly assessments, YaddaYaddaYadda. This is how you keep track of the genetically incompetent among us who drag everyone around them into the muck. You don't even have to be mean about it -- just maintain accurate records and the dumbshits' own incompetence will shine out of the darkness they created.

''I've seen documentation Dilbertized also. Documentation procedures can be as fucked up as bad code and bad coding practices. Counting things and counting important things are often not the same. Rather than create busy-work procedures and forms, have the problem coders write a weakly status report in English and keep an eye on their work. Explicitness will also sometimes get one black-listed. Many managers like to hide in the fog and target those who shine lights into it. Humans are not Vulcans, they are Ferrengi's. If you want influence, you usually can't tick off too many people, regardless of the merit of the tickage. That's just the rules of the Human Game.''

["Weakly"? Freudian slip, eh?]

I performed week proof reading :-|

------
Typical factors to consider (not necessarily a complete list nor mutually exclusive):

* Code Size - All else being equal, less code is better than more code. Related: LinesOfCode
* OnceAndOnlyOnce (arguably tied to "Code Size")
* Readability - Future maintainers have to find, read, and understand the code they are working with. Maintenance is typically roughly about 2/3 the cost of software.
* MentalIndexability - Does the design fit how we think about it? (This often relates to modularity.)
* Machine efficiency - Computer and network speed and resources
* "Staffable" - Can an org find and hire staff that knows the tools?

----
CategoryDecisionMaking