Perhaps, except that hypothetical code-hungry orcs are imaginary and have nothing to do with anything while the value of any of my very real examples is well understood by pretty much anyone. (Though - if you'll forgive me drawing further from our mystical beastiary - trolls might be an exception?)
Edit to explain why I'm so dismissive:
I think that it's a fairly accepted axiom that specified and documented projects are easier to maintain than the alternative. Likewise with code size versus feature set. I think it's self-evident that teams that communicate in natural language (even if only via a ticket system) are more functional (or at least more tolerable to be a member of) than teams that do not.
Deriving my claim from these seems reasonable enough, to me, given the context of the discussion (a comment thread of a relevant topic on some website a minority of people care about).
Not everything is science and while it might be nice to have 5-sigma data to reinforce my opinon, it fortunately doesn't need to be so reinforced in order to be valid, or even valid to be worth sharing.
> Perhaps, except that hypothetical code-hungry orcs are imaginary and have nothing to do with anything while the value of any of my very real examples is well understood by pretty much anyone.
What does this even mean? I don't see any real examples, and all you are doing is throwing more claims around. I missed the memo where you, and whoever this "everyone" else is were appointed authority on the value of anything for everyone else.
> Edit to explain why I'm so dismissive:
I think that it's a fairly accepted axiom that specified and documented projects are easier to maintain than the alternative.
So a project with beautiful documentation and totally retarded code is easier to maintain? Documentation, more often than not, is for the end user. As far as code maintenance goes, the most important factor is proper abstractions and encapsulations. If you wrote a 5000 line, well commented method, it doesn't help me at all.
And a very specific set of projects lead itself to and require beforehand specs. Majority of the real world runs on "code is spec". Where is the spec for linux? Here is a little unknown someone's views on specs http://kerneltrap.org/node/5725 Where are the specs for rails, sinatra, django, flask? And how would it help if suddenly a rails specs came into being? You are confusing your little well with the world. Most projects design interfaces, not specs(activerecord, rails 4 queuing api etc)
Even your axiom holds(it doesn't, at all), how does that imply if you're writing more code than natural language (documentation, discussion of specs, interaction with the team, etc) something is extremely wrong.?
> Deriving my claim from these seems reasonable enough, to me, given the context of the discussion
> Not everything is science and while it might be nice to have 5-sigma data to reinforce my opinon, it fortunately doesn't need to be so reinforced in order to be valid, or even valid to be worth sharing.
I didn't ask for 5-sigma data. I asked for data which isn't personal anecdotes and viewpoints presented as truth.
Edit to explain why I'm so dismissive:
I think that it's a fairly accepted axiom that specified and documented projects are easier to maintain than the alternative. Likewise with code size versus feature set. I think it's self-evident that teams that communicate in natural language (even if only via a ticket system) are more functional (or at least more tolerable to be a member of) than teams that do not.
Deriving my claim from these seems reasonable enough, to me, given the context of the discussion (a comment thread of a relevant topic on some website a minority of people care about).
Not everything is science and while it might be nice to have 5-sigma data to reinforce my opinon, it fortunately doesn't need to be so reinforced in order to be valid, or even valid to be worth sharing.