Workflow and Management Strategies

I kept saying, code review, when I just meant, "peer review".  Sorry for the confusion.

The Agile people feel that this is a horrible waste of time.

Just as long as it does not mean no foresight, no planning and no design before code. All things that have several ways of going about them and do not have readily available best know solutions or analysis, would have to be analyzed theoretically before coding. I do think that formal documentation should be a result of self-documentation. But I think certain documents are needed before coding so as to keep a clear goal and come up with a decent system.

Almost every project experience both scope change and scope creep.

A game project, esp something like ours, is rather unique in this regard. Most game projects are actually stories. Well ours is not but we still have a very strong idea of what the game should be. Hence our scope is fairly solid. At least we can easily identify parts that are very solid and will with 99.9% likelyhood never change. Then we can identify parts which might happen with our game..like we might make a complex weather system and plan for them by making the system flexible enough to handle it without change in code. Thirdly we can identify parts which will change with 99.9% likelyhood...the gfx engine being a prime example of that - due to evolving technology - and plan for that by making interfaces and connections between these parts fluid.

Henri and I have refactored the core of our project maybe 3-4 times.

Note that this is due to having no design at all before making any of those cores. If we had spent decent time on research and design. We would only have to make it once really. I never want to change core components again if possible. Anything that significantly changes architecture, should be finalized fairly early in the process. Also note that if we do see a part that might change (say the physics engine) we should build a robust and well designed interface which would not care if the engine does a 180.

That's what I was trying to say - not that we shouldn't do code review, just that it should be (if we do Scrum) part of our sprint review - a process we should do anyway. This is the point at which we go through the stories and UCs for the sprint and say actually do the stories and verify that the code follows the UC. It's the kind of thing that shouldn't take more than an hour or two between us.

Okay..the process you outline there is called "testing" and is by no means part of an iteration review (I have no idea about sprints and scrum and I do not intend to find out cuz I really do not care for things that other people came up with that much..and I do not have time to read). Iterations will advance no matter the outcome of the review. An iteration review would look at "what succeeded? Why? Could we use the same idea elsewhere? What failed? Why? How do we avoid it next time?" Testing is a process that happens during the development of the iteration and at the last leg of it once again - if errors are found they are fixed before the end of the iteration - that is if the iteration does not do what the chosen story beats said it would do. If something can not be done in time the storybeat will be abandoned and pushed into the next iteration or something like that..with a lot of analysis of course, why it could not be done this time. None of these are code-review. Testing is certainly a part of code review..the "If it looks right, it is right" part, but it is not a sufficient condition. Code review for me means - is my code quality code? Does it introduce problems in the future? Does it have potential scalability issues? Does it fail under any condition (this can not be achieved through testing in most cases - only analysis)? Things of that nature...in other words - other indicators of quality besides working in the test cases.

As far as real-time code review I think the "hey Matt, can you make sure I didn't do something stupid in foobar.cpp?" would be more than appropriate.

Now this is code review, but a highly inefficient way of doing it imo - this is exactly peer-review.

Also let me note as part of code quality control. We do need a way to check if changed broke some other part of the system...and we need a robust way to control that. Usual systems will employ unit tests (which are also good design methods btw). Unit tests in game and other interactive systems context are very difficult tho (how do you unit test shadows exactly?)...so we have to give this heavy thought and come up with a system. Obviously manpower in the form of testers is one way..things will certainly reveal themselves pretty quickly if the system is in constant beta-testing...as in there are always people playing the development version of the world.

That is not to say that we shouldn't have an idea of our architecture, throw together some enterprise architect diagrams or something. But we should keep it very high level. Don't document everything up front.

Just another note on this - how much documentation is needed up front? I do not know if I would actually call it documentation..it is a matter of definition. Just to be clear - what we do up front is done only to help development - if you have good design documentation, coding it will take very little time. So think of that as just a part of coding...you might even think of method names on paper (not uncommon..but quite pointless imo...what should rather be done is - a standard for method and class names ). What we should not do up front is create documentation that explains to others what the resulting system is like. That does not mean however that the original design docs are not useful as tools for explaining the system to others, but it is a side effect of those docs, rather than their purpose. Many new devs (myself included) learn more from the docs that were used to originally design the system, than something that was done as an afterthought or as javadoc/doxygen/whatever. In fact docs that have been created as an afterthought to explain the system to a "client" or whatever, are usually far more confusing than the original design docs (if there were any). Systems that have no original design docs are very hard to grasp and usually also pretty badly done (unless the coders were masters at the given area).

Hope that makes my opinion clear there.

What they've experienced is that a fair number of projects, RUP (Rational Unified Process) and Waterfall driven projects most commonly, have a documentation phase. This is where developers, designers and architects spend months writing specs and doing a bajillion UML diagrams.

 We all agree that overly centralized / command and control type development is a waste of time

The Agile people feel that this is a horrible waste of time. Let me explain why and then I'll explain their solution. Almost every project experience both scope change and scope creep. Take our little band of brothers here. Henri and I have refactored the core of our project maybe 3-4 times.

What happens when your project changes scope? You need to research and then redocument. This means, to a lot of organizations, enter that documentation phase again. Throw away all of your specs, UMLs and start all over. Do your discovery, write your new specs, draw up new UML class diagrams and process diagrams. Imagine doing this (potentially 3 month) process 3 or 4 times and imagine what your schedule now looks like. It's not good.

What Agile feels you should do is document as you go. That is not to say that we shouldn't have an idea of our architecture, throw together some enterprise architect diagrams or something. But we should keep it very high level. Don't document everything up front. Figure out what you want it to look like and document thruogh stories and code comments. Self document as much as you can and make per-unit documentation that assembles into a larger document. In summary document what you do, not what you will do over the next year.

I understand your sentiment but understand that we used Scrum at PLATO on 5 different software projects spanning more than 300 developers. It works. Besides, we're not going to be large enough to experience these issues for the foreseeable future. If Scrum (or some other non-XP Agile process) doesn't work fit our bill we're not obligated to continue using it. Scrum is very close to Iterative, for example, so it wouldn't really be that difficult of a transition to that.

What was the nature of the products? What was the outcome of the projects?  How was the chaos managed?   How was effective communication between teams and within teams maintained?  What sorts of documentation standards were implemented?  How was quality control maintained?