I’ve never understood this particular complaint about English. I can understand plenty of complaints. There’s loads of silly stuff going on in our language, like the lack of a gender-neutral pronoun.
But with the way our language works we do not need additional words to mean more-specific variations on one thing. Our language already supports that. If you need to be more specific than “complexity” you can easily specify that you’re talking about “time complexity” or “computational complexity” or “functional complexity” or “compositional complexity” or whatever other type of complexity you can ever think to specify. We don’t need extra words to do that.
If someone is describing things too vaguely that’s not a problem with English. The communicator just needs more practice at being meaningfully descriptive.
I’ve never developed a piece of software that’s Microsoft sized or that has had a Microsoft life cycle, so my perspective is going to be different to whatever is in that article.
On the topic of complexity, I agree in principle with the general shape graph in the first post about general complexity to time/cost. As a project grows you get increased overheads and certain tasks just take longer because there are more “moving pieces” to account for. There’s tools to mitigate all of that, but you’ll never get rid of it all entirely.
In my experience, after I reached the point where I thought I was actually alright at software development, the problem has never really been the size of a project. With enough understanding of various approaches and a decently experienced team you can design a solution to a problem, break it into pieces, identify which pieces need further research (if this isn’t needed then why are you writing software?) and how to account for the unknowns, and then start piecing stuff together. That’s not to say that it’s easy or that it’ll be perfect, but generally speaking a half-decent team should be able to do that and get good results.
(Edit: To clarify, I’m not saying that project scope doesn’t matter as long as a team is competent. I’m saying that it on its own isn’t the whole story.)
The real challenge comes from the realities of software development in the real world. The above paragraph basically assumes this fantasy wonderland where software developers are experts in their software’s applied domain (that’s rarely the case) and the originally designed solution never has to change (hah!). Lets examine each of those.
If you’re sitting there thinking “thankfully that doesn’t apply to game development”… think again! If you do think that then I don’t think you playtest enough. I’ve never playtested a feature, level or concept without coming away with some set of changes I’d like to make. (Though that doesn’t mean I always make them. At some point you need to decide you’re close enough and move on, or you’ll never complete anything non-trivial.)