8 hours ago, SillyCow said:

Avoid the 1 hour mandatory daily meeting at all costs.

An HOUR?? It should never be more than 15 minutes. 

19 hours ago, Fulcrum.013 said:

You can not build anything until you exactly know how to compute it. It have no any sence to start coding until you make a book called "mathematical description of a task" where complete described mathemathical background of any feature that have to be implemented

5

Quote

 

creationism n.    

The (false) belief that large, innovative software designs can be completely specified in advance and then painlessly magicked out of the void by the normal efforts of a team of normally talented programmers. In fact, experience has shown repeatedly that good designs arise only from evolutionary, exploratory interaction between one (or at most a small handful of) exceptionally able designer(s) and an active user population -- and that the first try at a big new idea is always wrong. Unfortunately, because these truths don't fit the planning models beloved of [3245]management, they are generally ignored.

 

Works about as well in software development as it does in biology.

8 hours ago, mr_tawan said:

It's then the customer chime in to help evaluating whether or not the implementation is correct and precise.

As i said software engineer have to work together with someone ecpirencied into process to determine universal process rules. Determined rules is constant  becouse it universal. So it have no any sence to code until complete set of process rules determined. It is how scientific-driven software development works into any fields including bussines, factory automation,  scientific software and anything else. AGILE/SCRUM e.t.c prefer to use ancient-age "try and errors" way. I guess it becouse authors of AGILE have not enought educdation. 

12 minutes ago, Fulcrum.013 said:

Determined rules is constant  becouse it universal. So it have no any sence to code until complete set of process rules determined. It is how scientific-driven software development works into any fields including bussines, factory automation,  scientific software and anything else.

But this isn't a scientific-driven software industry. We are neither automating factories nor writing autopilots. This is the video game industry - an artist-driven industry. We don't work the way other software engineers do. Our rules are neither constant nor universal. There are only the whims of the designers, marketers, and producers (especially producers!), and those whims are fickle indeed.

What you are saying simply does not apply to the world that I live and work in.

2 minutes ago, Oberon_Command said:

This is the video game industry - an artist-driven industry.

Any software development have 2 options: modern scientific-driven or ancient age mistake-driven. Even software that required for artist to implement a game features.Also it required advanced tech skills. For example most modern free engines stated that have option to develop game mechanics without coding skills. And it is true. But coding is just some thing like a pen into software engineering. Implementing of game features without coding can not be done without advanced software engineering education. For example without theory of automation control wich tools for creation a game mechanics without coding incapsulates.

Consider the following hypothetical story:

You're working on a tank game, something like a sci-fi, futuristic World of Tanks. In one of your playtests, a designer says, "It would be awesome if this tank could have some sort of rapid fire mode where they spew a bunch of projectiles really fast each time you fire! Like in a burst!" The other designers all hear this and agree that this does sound awesome. This wasn't in the original plan - there was no plan to support any such tank originally, but now the designers want it, and they want it fast. Like, by tomorrow morning fast.

It's pretty easy to modify the game to support this - the tank's cannon has a "cooldown" timer that you can just ignore for the first 6 shots (for example), with the number of shots per burst being data-driven (because of course the designers didn't tell you how many shots per burst they wanted :P). You wire up some logic quickly and get a build out to the designers. They playtest with it for a few hours, and then (rather glumly) decide that it isn't as awesome as they thought it was, please remove it. This is easy, because you made the whole thing data-driven, true enough. But furthermore, what would be more awesome, they decide, is if your tank could have an extra, smaller gun that behaved this way. So you go back and move your mods from the main gun logic to the auxiliary gun logic, get a build to the designers for them to fuss with... And round and round it goes.

A year later, an executive finds out about the old "burst shot on main cannon" mechanic and demands that you bring it back because "that other tank game we're competing with has it." And he's an executive, so of course you have to do it...

There is no constant, universal description of the tank game I just described. The designers just made shit up during a playtest and wanted to see how it would feel. The only specification of the game is a combination of what is already there, coupled with what work remaining is currently planned. Any of that work might be cancelled or deferred or new work created at any moment, at the whims of the people in charge. There is no fixed specification for this tank game. 

This is the kind of environment agile development evolved to serve. Which development methodology do you think is more suited for this kind of environment? I couldn't imagine doing this with waterfall. "Big design up front" is obviously impossible, because the specification wasn't known at the beginning. Or are you trying to argue that the designers shouldn't get to say anything more about the design once the programmers start? Or that programmers should have anticipated that the designers would want burst fire and implement support for it in advance? That definitely wouldn't happen - that time would be allocated to implementing stuff that designers want now.

30 minutes ago, Oberon_Command said:

You're working on a tank game, something like a sci-fi, futuristic World of Tanks

First we have to ask desinners what same thay want to adjust on effects. Than we have to search for similarities to find principles of adjusting. Than we have a little set of effects that can be extended anytime and set tiny set of adjusment controls tools that can be easely data-driven binded to effect parameters. As result we have a robust data driven designers environmet that never require a changes, just a some additions for effect sets in some cases.It is a way what real "Potatos"  (commonly used nickname of Wargaming here) use. It is how thay has made a high popular and profitable games with such tiny budgets and programmers team. "Snils" (Ganja Interactive) uses even more advanced technicue where most of vhechie parameters calculated from geometry model.

So by other worlds thay has just higly automated his designers work by  tools designed by modern scientific-driven development methodology, that allow to minimize dependences of  game design from engine/game code, so it require about zero iteraction betwin programmers and designers on initial geme design and not require programmers for tweak game objects at all.

22 minutes ago, Fulcrum.013 said:

"Snils" (Ganja Interactive) uses even more advanced technicue where most of vhechie parameters calculated from geometry model.

That's real neat and all, but in the example I gave, that technology is not only not available, it isn't necessarily relevant. This could (and probably would) happen in the prototyping stage - at this point, the tanks could be grey boxes driving around in obviously fake grass because the concept art team hasn't figured out what they're going to look like yet. The designer just wants to be able to do burst fire, to see how it feels, and the engine doesn't support that because, when you were doing the initial implementation, they didn't ask to be able to adjust that. So, the requirements for the software have changed from when you started. Without warning.

Imagine you don't have access to any of the technology you're talking about. What development methodology do you use to handle an environment where this happens? And don't just handwave "I ask the designers at the start of the project" or "I make everything tweakble" because, as I have repeatedly said, that isn't generally feasible. There simply isn't time to make everything tweakable in the kind of environment I'm talking about and there are always cases where they ask you for something that you didn't think of even if you do try to make all the things tweakable.

How do you handle cases where requirements change in the middle of the project with your methodology?

6 minutes ago, Oberon_Command said:

I gave, that technology is not only not available, it isn't relevan

Automatic control theory is regardless of control rules that it implements real or dummy. It just have to be set of rules to implement. How it rules related to real world is a problem of physics and other sciences, but not a automation conrol and even computer science. Subject of software engineering is to determine and implement a mathematical model of process by universal data-driven ajustable way regardless from wich source model came.

I think I'm going to stop responding to your posts in this thread now. You clearly don't have any desire to engage with my actual points and that is profoundly frustrating. Good day, sir.