ObsidianJones said:
Well, that's a good point that he's making...
If we didn't have a robust online gaming market. If that's the case, why couldn't they just ship it as free DLC? I mean, if he's saying that these things are being developed while the team is still technically being paid for processing, coding, and then shipping out the finished product, well.. it seems to fall into the scope of what the team was initially paid to do.
OK, I'm talking about software development in general, but I doubt the games industry is radically different - 1. employees get salaries. Yes, they do - in the software development, people still get paid monthly. OK, most of the time - although some are paid for the work they do (usually they aren't permanent employees but hired for just a project or, say, for a couple of months on several projects). While not uncommon, more on that just after 2. the
companies are paid per project. There are lengthy discussions between people, most probably in suits, who pin down and describe what the project is in details. There are big thick documents written that go at length on the matter - project specifications, functional requirements, drafts, proposals but bottom line is, a project isn't "make a game" or similar the scope of it is wa-a-a-ay better mapped. At the very least, you'd come up with a list of FR (functional requirements) after the initial meetings but usually, you'd also get a project specification talking about it in general. Once you have those, you're ready to start actually
planning. And after brief planning, the developers would be able to tell how much it actually costs. It's not uncommon to pay per man hour expected (that would be an estimate, of course) or sometimes the final price may be presented after the project finishes - if there were 1000 man hours poured into it, the customer pays for those, if it amounted to 1500, then that's the final price. Maybe with some extra cost included (you could have a start sum plus whatever you choose to charge per man hour). Or there could be an alternative payment method - per feature, for example, or similar but bottom line is, the company is not expected to just add random stuff as they go along. There is a term for that - feature creep. And it's bad, it's very bad for a software project.
There is a common misconception that software development is "oh, just add this". It's not, and I don't think I can properly explain the full reasons why is that. There are
books written on the matter that are tackling this from different sides.
And your analogy is very flawed. What you described there is referred to as implicit requirement - one, that's too simple to properly convey the actual complexity of the task involved, two, it's just stupid. What my old boss used was a much better analogy - imagine starting to build a house and you hire some people to do that. Now, if you suddenly decide you want an extra room, is that not extra work for the builders? If you want an extra floor, is that not extra effort and time? Heck, maybe the house is more or less finished on the outside but if you decide you want changes in it, like putting more windows or something, "while it's not complete yet", how is that not extra stuff to do? I've also worked at a building site, and I'm telling you - if somebody came and said "Oh, good work chaps, I'm liking how the thing looks. But can you just erect a wall here and change the ceiling? Oh, I won't pay you for the work and I still expect it to be finished at the time we agreed." they'd probably get a slap.