|
|
|
|
|
|
by stcredzero
6261 days ago
|
|
|
"Another classic error we committed was trying to develop generic tools with a view to possible future productions, rather than tools dedicated to the experience of the game we wanted to create." I wonder if there's a lesson here for programming languages? Kernihan and Ritchie developed C for their needs of the moment (Implementing SpaceWar on a PDP-11) and it became wildly successful as a language. Maybe feedback from actual use generally trumps design up-front for languages? |
|
|
Projects where the tools and frameworks are designed solely for the problems at hand get burned because the specifications change (see point 1 in the original article), and the tools are not flexible enough for the new requirements. Projects where the tools are flexible end up burned either: (1) because the tools are not flexible enough, and therefore suck, (2) because the tools took too long to develop, and project work never got done, or (3) because the tools were too flexible for the programming team which ended up abusing them and writing unmaintainable code.
It may be a tough pill to swallow, but projects succeed and fail because of the people. Not because of procedures, but solely because of the people. Talented, determined, bright people will find a way to ship a product, will work their way out of any mess. Depending on the project, and depending on luck, the required degree of talent, determination, and intelligence varies. No matter how much the "project management" industry wants to sell books and classes and software, everything comes down to brainpower.