I wanted to add my 2 cents on this. I've consulted with many, many game development firms of all sizes from the very big (1000+ employees) to the very small (2-3 people) and help them implement sound development practices based on well known software development methodologies, and after waiting a while for this game to come out it raises serious questions about how the company operates it's development side of the business.
I can forgive the fact that a bad upload went out to Steam. I question using Steam at all but they have a solid reputation as a game delivery platform, so that's fine.
This part here is unacceptable:
**Thanks to various factors we are now sitting on top of a pile of blown apart code and unstable features**
Blown apart code...? Unstable features!?!?! In any given industry where software is being built, and games are a form of software, the code is the lifeblood of your business, the single most important asset you posses. There's no reason, and no excuse, for a team of developers to ever be sitting on top of a pile of blown apart code no matter what stage of development or what crises/meltdown has occurred. When using even the most basic and limited tools and practices of change management (eg; an SCM system) an established baseline at each milestone is preserved allowing the shop to roll back to the that last known stable milestone in the event of a catastrophe, as what appears to have occurred here.
So what has had to have happened is:
1.) Kerberos are not following even basic process of proper software development
2.) If they are and have been maintaining baselines (eg; daily, weekly, backups of a stable codebase) then they have not been following even the basic process of proper design and practice which demands a stable code base at all times (you're Head revision or Mainline if you will) with unstable changes kept in isolation (eg; branches) until proper testing and integration can be performed. So at no time should there ever be a pile of blown apart code and unstable features, not on the first day of development, not on the last day or any time in between!
What bothers me is not the initial mistake, being involved in operations like this many times myself you know that things happen, not being able to recover instantly due to what I can sense is an amateurish approach to change management, lax standards for design and practices, that's not forgivable and suggests and larger more serious issue that won't be corrected in a flurry of code-and-fix development as opposed to the adoption of a proper practices.
The days of Cowboy coding are long over and no gamedev shop will last for long with the approach. My suggestion, hire a consultant, adopt Scrum for project management, refer to XP practices for proper design recommendations, and implement the proper tools and utilities necessary to ensure it would be impossible for something like this to ever happen again in the future.
I can forgive the fact that a bad upload went out to Steam. I question using Steam at all but they have a solid reputation as a game delivery platform, so that's fine.
This part here is unacceptable:
**Thanks to various factors we are now sitting on top of a pile of blown apart code and unstable features**
Blown apart code...? Unstable features!?!?! In any given industry where software is being built, and games are a form of software, the code is the lifeblood of your business, the single most important asset you posses. There's no reason, and no excuse, for a team of developers to ever be sitting on top of a pile of blown apart code no matter what stage of development or what crises/meltdown has occurred. When using even the most basic and limited tools and practices of change management (eg; an SCM system) an established baseline at each milestone is preserved allowing the shop to roll back to the that last known stable milestone in the event of a catastrophe, as what appears to have occurred here.
So what has had to have happened is:
1.) Kerberos are not following even basic process of proper software development
2.) If they are and have been maintaining baselines (eg; daily, weekly, backups of a stable codebase) then they have not been following even the basic process of proper design and practice which demands a stable code base at all times (you're Head revision or Mainline if you will) with unstable changes kept in isolation (eg; branches) until proper testing and integration can be performed. So at no time should there ever be a pile of blown apart code and unstable features, not on the first day of development, not on the last day or any time in between!
What bothers me is not the initial mistake, being involved in operations like this many times myself you know that things happen, not being able to recover instantly due to what I can sense is an amateurish approach to change management, lax standards for design and practices, that's not forgivable and suggests and larger more serious issue that won't be corrected in a flurry of code-and-fix development as opposed to the adoption of a proper practices.
The days of Cowboy coding are long over and no gamedev shop will last for long with the approach. My suggestion, hire a consultant, adopt Scrum for project management, refer to XP practices for proper design recommendations, and implement the proper tools and utilities necessary to ensure it would be impossible for something like this to ever happen again in the future.
