That article explains little about the FD mindset, it's a rather broad opinion and floats several unspecified excuses as to why we should cut game developers some latitude. Are IT projects any different no matter what the discipline? We plan every day to deliver mobile apps for our clients and one thing remains constant. Good project planning, communication and managing expectations are central to ensuring that your clients are happy. These things seem to escape the games industry, who a adopt a taciturn approach. In my opinion they are master of their own fate.
With regards to the game I agree its OK, the adage "mile wide, inch deep" has some connotations.
Are IT projects any different no matter what the discipline? There are a few things that are the same, which you mentioned, but there are other aspects that make them completely different:
The type of application being developed. Would you approach a desktop application the same way you'd approach a mobile application? No. Why? Because they're completely different platforms; ergo you must take numerous other, platform specific, scenarios into account during design and development. You must approach the entire project from a different angle. I can't take the approach I've taken to my current project (desktop) and apply it to a mobile app, it won't work.
The size of the application. The bigger the application, the more development needed (obviously); this results in an increase of the chance of conflicting modules; usually greater hardware requirements (space, CPU, memory) and so on. These changes can, and often do, impact design decisions down the line. A feature originally planned might cause too many problems and is subsequently scrapped.
Planned vs Implementation. Sometimes good ideas that seem simple on paper, turn out out to be either bad ideas or incredibly difficult to implement given their function and impact on other parts of the application. Over-complicated features that cause too much trouble than they're worth, features that are not financially feasible at the time, or even features that break the time constraint will either be scrapped or put on hold.
It's very easy to say "Oh, we can just do X" during design and Kickstarter, and make huge promises. But FD had a deadline to meet, and as such, they had to put features on hold that had been initially promised simply because they either under-estimated the complexity of the features they wanted to add (I myself have put about 3 features on hold in my application because we found later on that they'll take up too much time to development and implement, so they won't be in the initial release), or over-estimated their own abilities ("feature x is easy to do" .. 6 months later .. "ok, no, feature x is not quite that easy and breaks a lot of other things in the process. it'll take another 6 months to complete.") Either way, these things happen and are par for the course in development; plans change.
The life of the project. The life of the project determines the SDLC used (long term? short term?), release planning, it determines timelines for feature development, priorities, features in general, bug fixing schedules (it's better to have the dev's who worked on a module, bug fix that module, instead of having another dev who didn't work on it, try to fix it and potentially break it and other things).
So, yes, cut the game developers some slack. Appreciate what it is they are doing. Use the article to take an interest and garner a small understanding of what it takes to make a game, and just appreciate what it is they've managed to deliver in TWO years.
