On Thu, May 28, 2009 at 5:59 AM, Conal Elliott
Thanks for bringing in this angle, David.
My preference is for honest and humble practice and documentation of negative design. Instead of saying that something "won't work", "can't work", "is impossible" etc (or rephrased via "must", "only", etc), I'd like honest admissions like "I couldn't figure out X", "I got stuck on Y", etc. After all, someone else might get further. Or, in the rare cases, when something actually is impossible, say so prove it.
Yes, this angle is important, escpecially if you like me read a lot of code and end up thinking "why is this code so complicated, there must be an easier way". I often feel that thinking like that prevents quick understanding of the code, simply because my brain is pre-occupied with solving the problem more elegantly while trying to understand what is going on :-) Often a particular solution isn't impossible to use (i.e. the words "can't", "won't" etc shouldn't be used), instead solutions aren't as good as others when resource constraints into account. Of course the "negative reasons" must be backed up with data (sometimes rough estimates are enough), but this brings me to other pet peeves of mine at work, the general lack of non-functional requirements and prototyping with performance tests. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe