BI Staff, what software development model are you using for DayZ?

[pilgrim* 3514]

1 hour ago, robbyj said:

agile really calls for rapid software development and software that can respond quickly to changing requirements without excessive rework. customer involvement? sure. incremental delivery? if delivering the same version week after week with different sounds or colors counts, yes. people over process? all i see is people leaving, maybe not a good team to begin with. embrace change? no. maintain simplicity? no. overall i'd give their agile score badly damaged PU scope / 10

yeahn I know what "Agile" means as a concept, and I explain it's limitations. Realise that BI is UNIQUE among software developers (this is the KEY)  for a number of SPECIFIC reasons. Then READ my suggestions of why BI doesn't fit into your conceptual box. - Read up on BI and find out how they actually work, look at their record and their methods. You say, confidently  <<people over process>>... but in fact you are glorifying a Process. That's just fanaticism. There will be a new buzzword soon and Disney and Apple will be using it to cover whatever the hell it is they do. As always.

All these process terms are simply TOOLS .. You pick them up when you want to use them, and you throw them back in the  box when you want to use something else, or you leave them to rust, or you redesign or modify them, or you build your own. YOU make the decision, not Marshal McLuhan, not Kant, not Ford, not Musashi, not Trump or Mao or the Pope - and in the case of BI, not your shareholders. Jobs and Ford and Gates and Disney (the man) were NOT successful because they followed someone's RULE BOOK about how to do it - totally the opposite.  They went their own way and did NOT do what they were supposed to do.

AND plenty of individuals have thrown away the latest COOL rule book and then totally FAILED, too.. which makes me think that a "How To Be Original and Successful" pocketbook of big-time new-age flowcharts is ONLY as useful as you think it is, definitely no more and no less..  You CANT judge ORIGINALITY or CREATIVITY or SUCCESS by a flow chart .. YOU judge how useful it is, it doesn't judge how useful YOU are.

Only Accountants really DELIBERATELY use standard methodology - they do it to make sure they are NOT Unique.

If you are half way up in an organization you can use the accepted company "methodology" as evidence on paper to cover your @ss so nobody can say it was your fault.
<<Hey dude, I'm AGILE, get off my back>> 
What else are bullet-point methodologies good for, seriously, however trendy they are?   If you want to TRY to WIN they are good for perhaps noting they exist and then being Creatively MISUSED, crossbred and MUTATED. Methodologies are ZOMBIES. And you don't in fact need to know the buzzwords to mutate the zombie. You just need your brain working inside a team. 

By the way - Have you ever EVER been to a REALLY GOOD Power Point presentation ever ever ever about ANYTHING AT ALL ever in your entire life ?? 
(heh)  - just wondering. Me neither.

 

* * *

It's really easy to knock Dayz and show how they do everything wrong (plenty of folk are doing that right now)
And it's really easy to show how Pokemon did everything right (really big success, still going strong)
That's true.
But - if I had to make the choice for myself between just one of those two games
- which would I choose ?
 

 

Edited December 20, 2018 by pilgrim*
IMO, natch - xxP

[bfisher 561]

 

[bfisher 561]

On ‎12‎/‎18‎/‎2018 at 3:39 PM, pilgrim* said:

for those who haven't heard of "Waterfall" & "Agile"

"Waterfall"
The waterfall model is a relatively linear sequential design approach for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches.
The waterfall development model originated in the manufacturing and construction industries; where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process [compared to software engineering].
When first adopted for software development, there were no recognized alternatives for knowledge-based creative work.
= seriously obsolete in software development

"Agile"
Agile software development is a theoretical approach to software development,  such that requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer /end user. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
It is useful and natural,  for only very small startup developers to use this technique instinctively.

1) In the BI structure, the "self-organizing" development team's only 'customer' is BI itself. This is to a large extent their INTERNAL practice.
2 ) End users are not a stable group with defined common ground, and their desires and expectations change through time, sometimes irrationally, users are in flux and sometimes in strong disagreement, improvements are moot, and changing factions seek fundamentally different outcomes.

= For "Agile", to be cost effective, except at minimal scale and with payback time not a consideration (eg spare-time indies and modders), requires the specific preliminary targeting of a single "end user" group, and developing to their taste alone, deliberately ignoring other possible interests or users. It is useful [for instance] for the production of mass popularity games of low complexity (Lowest Common Denominator games) and Apps.  This renders "Agile" a simple, non-flexible technique, useful for outsourcing.

xxP

=IMO, naturally =

 

I don't know if waterfall is completely obsolete.  But as you say, it is a sequential, relatively rigid approach to software building - Usually some variation of Plan, Design, Build, Test, Validate, Release.  The main problem is that you often don't know what you don't know in the Plan and Design phase and it's prohibitively expensive to find out.  That uncertainty often doesn't manifest itself until Testing and Validation, often requiring major expensive rework.  Stress tends to build midway through the project as deadlines slip and project managers push their teams to compress the work so they can deliver to the original milestones.  Projects often go off the rails at the end where you end up with this long tail of bugfixing and scope changes.  Then it's just developers working feverishly to try to make everything just work. (sound like anyone we know?)

Agile tries to mitigate this by delivering complete modules of software at regular intervals or "sprints".  It's not just a "philosophy".  It requires functionality to be built and created in a very modular and self contained way so that there is minimal rework.  If DayZ were delivered using an Agile methodology, I would expect that the first release would be a relatively stable, if empty world.  Each week (or whatever the sprint lengths are), I would expect to see something new added.  Some weeks it might just be bug fixes.  Other weeks, it might be "ground vehicles" or a new gun.