To any programmers here about....eh...programming...

[Scott_Arm]

Following some type of software development cycle like the waterfall method or RAD or anything of the sort.

Proper preliminary investigation, analysis and design documents ie well defined requirements and a clear and well researched design

quality tools with support

A good manager (I also agree about throwing people at a problem)

dedicated co-workers.

A customer that doesn't constantly change her/his mind

 

[Nite_Hawk]

I tried Eclipse a while back. It shattered my nerves, turning me into a shadow of my former self. I still sometimes wake up in the middle of the night in a cold sweat, gasping for breath. I have to load up Visual Studio and hit "new project" just to calm myself enough to get back to sleep...

Even just writing this post has given me flashbacks. I need alcohol. Lots of alcohol.

That's what people who are forced to use clearcase and rational rose around here say all the time.

Nite_Hawk

 

[ERP]

Proper preliminary investigation, analysis and design documents ie well defined requirements and a clear and well researched design

A customer that doesn't constantly change her/his mind

And here is the challenge in game development
Because the first point is close to impossible, because of the second point.

IME there are VERY few designers in the games industry, who can viisualise and communicate what they want to build in any way upfront.

Game Software engineering is about hedging bets and building systems for ever changing design requirements. The best set of requirements in the world don't really help much if the result of them isn't fun.

 

[Scott_Arm]

Are the new Borland builders any good?

 

[MrWibble]

That's what people who are forced to use clearcase and rational rose around here say all the time.

Nite_Hawk

Clearcase... nooooooooo..... I was blocking that one out.

/pours himself another drink.

 

[Scott_Arm]

And here is the challenge in game development
Because the first point is close to impossible, because of the second point.

IME there are VERY few designers in the games industry, who can viisualise and communicate what they want to build in any way upfront.

Game Software engineering is about hedging bets and building systems for ever changing design requirements. The best set of requirements in the world don't really help much if the result of them isn't fun.

I imagine writing these documents for a game is much more difficult than writing these documents for an online shopping system where you can sit down with a rep of some company and have them describe what their site will have to do.

At the same time, I think you can write these documents for games, and though a little more vague, they'd still keep people more productive than if they didn't have them. The biggest problem with games seems to be overambition and feature creep. These documents are supposed to do away with that kind of thing. If I was a publisher, I wouldn't front any money to a company that didn't show me they had some kind of scope and plan for their game.

 

[Nite_Hawk]

I imagine writing these documents for a game is much more difficult than writing these documents for an online shopping system where you can sit down with a rep of some company and have them describe what their site will have to do.

At the same time, I think you can write these documents for games, and though a little more vague, they'd still keep people more productive than if they didn't have them. The biggest problem with games seems to be overambition and feature creep. These documents are supposed to do away with that kind of thing. If I was a publisher, I wouldn't front any money to a company that didn't show me they had some kind of scope and plan for their game.

Believe me, these problems are not confined to the game industry. Unfortunately these kinds of documents end up being thrown away when requirements change. Let me post a conundrum, is it better to have these documents, and violate them all over the place later on in the project, or to just say to hell with it and not bother with them in the first place?

Nite_Hawk

 

[Bobbler]

Believe me, these problems are not confined to the game industry. Unfortunately these kinds of documents end up being thrown away when requirements change. Let me post a conundrum, is it better to have these documents, and violate them all over the place later on in the project, or to just say to hell with it and not bother with them in the first place?

Nite_Hawk

To hell with it =o

 

[MrWibble]

I imagine writing these documents for a game is much more difficult than writing these documents for an online shopping system where you can sit down with a rep of some company and have them describe what their site will have to do.

At the same time, I think you can write these documents for games, and though a little more vague, they'd still keep people more productive than if they didn't have them. The biggest problem with games seems to be overambition and feature creep. These documents are supposed to do away with that kind of thing. If I was a publisher, I wouldn't front any money to a company that didn't show me they had some kind of scope and plan for their game.

In my experience it's the person fronting the money (i.e. usually the publisher) who is often most guilty of moving the goal posts mid-project.

It seems to me that the problem is it's an industry which is victim to changing trends, fashions, constant hardware changes (even though Consoles have a longer life-cycle, PC technology has an impact on expectations), technical advances in software... Combine that with a production process that takes something like 18 months on average and it's easy to see that things can spring up frequently throughout production that will make a team (or management) want to change a design, possibly radically.

Of course that's not to say that things couldn't be run a whole lot more professionally in a lot of companies, and indeed some software houses do seem to be able to produce reasonable titles on time without stupid crunch periods or other hiccups.

 

[MrWibble]

Believe me, these problems are not confined to the game industry. Unfortunately these kinds of documents end up being thrown away when requirements change. Let me post a conundrum, is it better to have these documents, and violate them all over the place later on in the project, or to just say to hell with it and not bother with them in the first place?

Nite_Hawk

I'd rather have the documents, and have them updated or changed when necessary, with management having to sign off on an extension to the schedule to accomodate.

I don't mind working without a schedule and adapting stuff on a whim, but the flipside is that when asked "when will it be finished" the answer is going to be "when it's done". Generally that answer isn't acceptable to those writing the cheques, so if I have to give a firm date, I want a firm description of what I have to write.

 

[BRiT]

That's what people who are forced to use clearcase and rational rose around here say all the time.

Make. It. Stop!

/me reaches for his fifth...

 

[BRiT]

Unfortunately these kinds of documents end up being thrown away when requirements change. Let me post a conundrum, is it better to have these documents, and violate them all over the place later on in the project, or to just say to hell with it and not bother with them in the first place?

A better way to deal with this is to switch over to an Agile-based development methodology. The project is broken out into multiple releases, typically consisting of 5 or 6 iterations. Each iteration is typically two weeks. Features and functionality are broken down into manageable units that should be completed within an iteration. At the end of an iteration, the software should be functional, but not neccessarily functionally complete. (ie: application is capable of reading/writing/managing objects, but the UI is not hooked up or the user is able to perform a subset of action (submission only but not view submissions))

At the beginning of each release, one has the planning game. This is where an overall goal and base set of features/functionality are scoped off and the team can determine an appropriate overall architecture to use or follow during the release. Now during the time work is being done in an interation, the requirements should remain fairly static, unless the changes are minor. If a feature isn't locked down or is changing too much, then work on it should be delayed. It should not be changed when someone is in the middle of implementation. What one needs to account for is some time to allocate to refactoring when implementing features on top of the current code-base. The flexibility and overall higher productivity of always having something mostly functional far exceeds any costs spent on refactoring. It may not be the end-all-be-all, but it handles changes more graceful than other methodologies I had the misfortune of using (RUP/Waterfall/BigBang/etc).

 

[Scott_Arm]

I'd rather have the documents, and have them updated or changed when necessary, with management having to sign off on an extension to the schedule to accomodate.

I don't mind working without a schedule and adapting stuff on a whim, but the flipside is that when asked "when will it be finished" the answer is going to be "when it's done". Generally that answer isn't acceptable to those writing the cheques, so if I have to give a firm date, I want a firm description of what I have to write.

I agree. I'd never throw those documents out. I'd change them and update them. It's important to have a clear scope, and know which requirements are essential, and which ones can be pushed.

 

[Scott_Arm]

A better way to deal with this is to switch over to an Agile-based development methodology. The project is broken out into multiple releases, typically consisting of 5 or 6 iterations. Each iteration is typically two weeks. Features and functionality are broken down into manageable units that should be completed within an iteration. At the end of an iteration, the software should be functional, but not neccessarily functionally complete. (ie: application is capable of reading/writing/managing objects, but the UI is not hooked up or the user is able to perform a subset of action (submission only but not view submissions))

At the beginning of each release, one has the planning game. This is where an overall goal and base set of features/functionality are scoped off and the team can determine an appropriate overall architecture to use or follow during the release. Now during the time work is being done in an interation, the requirements should remain fairly static, unless the changes are minor. If a feature isn't locked down or is changing too much, then work on it should be delayed. It should not be changed when someone is in the middle of implementation. What one needs to account for is some time to allocate to refactoring when implementing features on top of the current code-base. The flexibility and overall higher productivity of always having something mostly functional far exceeds any costs spent on refactoring. It may not be the end-all-be-all, but it handles changes more graceful than other methodologies I had the misfortune of using (RUP/Waterfall/BigBang/etc).

I would definitely want to stay away from Waterfall for a game.

 

[Nite_Hawk]

A better way to deal with this is to switch over to an Agile-based development methodology. The project is broken out into multiple releases, typically consisting of 5 or 6 iterations. Each iteration is typically two weeks. Features and functionality are broken down into manageable units that should be completed within an iteration. At the end of an iteration, the software should be functional, but not neccessarily functionally complete. (ie: application is capable of reading/writing/managing objects, but the UI is not hooked up or the user is able to perform a subset of action (submission only but not view submissions))

At the beginning of each release, one has the planning game. This is where an overall goal and base set of features/functionality are scoped off and the team can determine an appropriate overall architecture to use or follow during the release. Now during the time work is being done in an interation, the requirements should remain fairly static, unless the changes are minor. If a feature isn't locked down or is changing too much, then work on it should be delayed. It should not be changed when someone is in the middle of implementation. What one needs to account for is some time to allocate to refactoring when implementing features on top of the current code-base. The flexibility and overall higher productivity of always having something mostly functional far exceeds any costs spent on refactoring. It may not be the end-all-be-all, but it handles changes more graceful than other methodologies I had the misfortune of using (RUP/Waterfall/BigBang/etc).

We tried this. It sort of works, but there are downsides. People would allocate 2 weeks for tasks that would only take 1 and would sluff off the remaining time. On the other hand, some tasks took longer and people got frustrated when they were held accountable to get a task done in 2 weeks. Finally, it didn't really solve our problem. After 12 weeks of 2 week tasks, a release would be made, goals re-evaluated, and we'd just end up ripping things apart just like we did without the two week task system. Honestly it didn't really seem any better to me than assigning tasks on a per-task basis with 3-4 month release iterations.

Nite_Hawk

 

[Sis]

We tried this. It sort of works, but there are downsides. People would allocate 2 weeks for tasks that would only take 1 and would sluff off the remaining time. On the other hand, some tasks took longer and people got frustrated when they were held accountable to get a task done in 2 weeks. Finally, it didn't really solve our problem. After 12 weeks of 2 week tasks, a release would be made, goals re-evaluated, and we'd just end up ripping things apart just like we did without the two week task system. Honestly it didn't really seem any better to me than assigning tasks on a per-task basis with 3-4 month release iterations.

Nite_Hawk

2 weeks sounds a bit short. We recently had a lot of success with a 6 week iteration where we basically said features X, Y, Z had to be code complete but not test complete. This gave us the flexibility and timing to do some proper architecture while maintaining a time pressure and having quick deliverables. We stacked up these iterations and left one final one for re-work. Some features would iterate over two iterations cycles, with the first being an interface complete, the second being functionality complete.

During it we also learned that you should not start one iteration immediately following the end of another, but instead pad them by a few days or one week.

.Sis

 

[Laa-Yosh]

Well, at least it's good to know that we're not the only ones having to fight less then perfect software tools...

 

[BRiT]

We tried this. It sort of works, but there are downsides. People would allocate 2 weeks for tasks that would only take 1 and would sluff off the remaining time. On the other hand, some tasks took longer and people got frustrated when they were held accountable to get a task done in 2 weeks. Finally, it didn't really solve our problem. After 12 weeks of 2 week tasks, a release would be made, goals re-evaluated, and we'd just end up ripping things apart just like we did without the two week task system. Honestly it didn't really seem any better to me than assigning tasks on a per-task basis with 3-4 month release iterations.

Ah, I can see why that wouldn't have worked to the fullest or all that well for you.

In our project, we task out all features after IPM, iteration planning meeting where the upcoming features (stories) are presented to everyone on the team with the stake-holders/customers there. During tasking, for each story, we would break it up into smaller parts of what needs to be done. From there we estimate how long each piece is likely to take as well as noting risks. Some stories would come in as 12 tasks but only 2 units total (16 hours), some would come in as 5 tasks but 9 units (the entire iteration). We would then tally how many stories (from a unit standpoint) we felt we could accomplish in the iteration given current staffing and level of risks. The team commited to so many units, but would always try to accomplish as much as possible and in the order of priority.

It wasn't until after all of this was completed that we would figure out who was working on what. We also made use of Pairing. Sometimes we had assigned an expert along with someone else to work on an area of risk. Sometimes we draw randomly to see who would be working on what. Other times we would rock-paper-scissors for stories. A few times it would fall down to "Anyone want to work on ABC123?" or "Who wants to work on XYZ789 with me?". We've also had some stories that were large enough, but was tasked well enough to be split across 3 pairs. We would also switch up pairs throughout the iteration and sometimes mid-way through a story if it was at a logical breaking-point. In this way, everyone was held accountable for the progress of the project and no one felt singled-out or shafted.

We also considered proper unit-testing to be part of each story and task. The story would not be marked complete until the unit-tests were complete. For the most part, everyone followed and stuck with this. Those who made it a habbit of not creating proper tests were voted off the team.

 

[Fafalada]

That's what people who are forced to use clearcase and rational rose around here say all the time.

NOT funny - I'm using Clearcase as we speak... Honestly it's not so much using it that gives me headaches (nothing could ever come close to the horrors of using SourceSafe for 2 years back in 1998-2000) - it's administration.
Last summer I had to upgrade from Server2k to 2k3, new domain, and consequently a new version of ClearCase. Somewhere midway through the process I got very close to giving up and just throwing away our entire existing database because I no longer had faith that I could ever get the new software to work with it.

My biggest gripes with it are all "minor", I can't display the same file in two Horizontally adjacent windows for example.

You could use splitters to do that (vertical and horizontal) in VS6. I honestly never tried to do it in 7 so I'm not sure if it still works (as I never really used it in 6 to begin with).
Anyway, 6.0 was all flowers and roses for me after having to put up with 4 and 5.
Transition to 7 wasn't as smooth, but that could be just me getting older

The editor is still the most important part of an IDE for me, the main reason I swapped to the VS6/7 one was because I wanted consistent keys between code editing and editing in the debugger

Well to me there's a number of widgets (all of which have been incorporated into latest version of VisualAssist now, in MSDev6 I had to use multiple plugins) that I am really used to.
Which is the main reason why I am not comfortable with Eclipse atm.

I imagine writing these documents for a game is much more difficult than writing these documents for an online shopping system where you can sit down with a rep of some company and have them describe what their site will have to do.

Assuming that the said company rep. has a decent idea what they actually want - which during my experience in the field(before I worked in games) was not very often at all.
That was the time when I learned the term "custom built" application apparently gave the customer freedom to completely change their minds about the application spec. about 5 times a minute.

 

[ERP]

You could use splitters to do that (vertical and horizontal) in VS6. I honestly never tried to do it in 7 so I'm not sure if it still works (as I never really used it in 6 to begin with).
Anyway, 6.0 was all flowers and roses for me after having to put up with 4 and 5.
Transition to 7 wasn't as smooth, but that could be just me getting older

Yes you could do that, but then you couldn't scroll them independantly, so it was brain dead in 6 aswell. This one feature was the reason I refused to use the editor for many years. In the end I just gave up.