Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[noob]

Are you kidding? I would build a real life fortress full of magma and hire a bunch of BDSM folk to dress as elves and keep them in cages.

this

[LemonFrosted]

To the fellow who just can't believe that adding people slows things down: yes, that disbelief and "common sense" thinking is precisely why people keep trying to speed up projects by adding staff in midstream. It ALWAYS slows things down. This isn't my opinion; this is the finding of years of research into the (important) question "why do big software projects always take so !%!%ing long." Read "The Mythical Man-Month" that Cydonia referred to, or just look at this precis: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

That example doesn't apply to this situation at all.

DF has ONE person doing many, many different tasks and working at his own speed.  That is completely different from anything mentioned on that MMM wiki page.  Adding skilled people to this project is highly unlikely to cause these problems.

The wiki page says that the central theme of MMM is "adding manpower to a late software project makes it later".  Is that what we are talking about here?  I'm not.

In regards to big projects...ALL big projects start with a small team that grows.  ALL of them.  You don't hire 100-200 people and bring them in all at once when the project is in phase 1.  As the project grows, the team grows.  As the years go by, people come and go naturally with attrition or need.

Obviously, I don't disagree that problems mentioned in the MMM can occur.  They do and often.  But well managed projects do their best to minimize the impact.  Sometimes you just need more people.

This, for the most part.

You'd be hard pressed to convince me that hiring an intern, an understudy, and a business manager would make things move slower. Intern handles mundane tasks, understudy spends time doing repetitive gruntwork like updating RAWs and managing the bug tracker, business manager does business managing.

[bobhayes]

You'd be hard pressed to convince me that hiring an intern, an understudy, and a business manager would make things move slower. Intern handles mundane tasks, understudy spends time doing repetitive gruntwork like updating RAWs and managing the bug tracker, business manager does business managing.

Intern interrupts Toady six times a day to ask for guidance, understudy puts Toady six months behind as Toady, the only person who understands the project, brings him up to speed, business manager cuts an hour a day out of Toady's schedule with questions, suggestions, and makework designed to make the business manager seem indispensable.

Then the understudy quits to write their own game, the business manager and the intern start a torrid office romance that brings further distractions to the office, and Toady grimly adds the "Management" arc to the game to model the appalling clusterf*** that his devcycle has become.

[HungryHobo]

That example doesn't apply to this situation at all.

Yes. yes it does.

You're trying to apply how you *feel* it should work rather than what actally happens.

It's a similar problem to parallel programming.
Only instead of CPU's you have a load of vaguely predictable human beings each with their own drama, off days, problems and issues.

If done exceptionally carefully with a project which was designed from the start to be developed that way then it can be done.
But it's hard. that's why so many big software projects fail utterly.
nailing it on to a partly done project is a death sentence.

It isn't even a case of bringing people up to speed.
each node you add increases the communication overhead no matter how good they are.
1 node: no communications overhead.
2 nodes: 1 path.
3 nodes: 3 paths.
4 nodes: 6 paths.
5 nodes: 10 paths.
6 nodes: 15 paths.
etc

nodes increase liniarly, paths do not.
 
The guy writing the pathing code has to talk to the guy writing the code for handling animal movement or else when they put their 2 pieces of code together it just doesn't work.
They have to communicate: even if it's only in the form of insanely detailed requirements documents.

You get more bugs with 2 coders because the 2 might have subtly different ideas about how some data should be handled.

Some stuff can be split off into an entirely seperate thread with little or no communication with the main thread as long as the project has been designed as such: for example the RAWs which has been designed so that modders can do their thing without ever speaking a word to toady.
but then that's already being handled by the modders.

[Malibu Stacey]

You get more bugs with 2 coders because the 2 might have subtly different ideas about how some data should be handled.

2 or more people coding would create more bugs than there are currently in the game? Really? Are you trolling us in some way only people with Agile development experience/PRINCE2 accreditation will get or something?
Ever heard of peer review? You're honestly trying to tell us that having someone else work on fixing the bugs or at the very least casting an informed eye over the code would cause more bugs? I can think of about a dozen bugs I could fix myself in this game without even having looked at the code yet (uninitialized value for glass MAX_EDGE causing glass to either be completely useless for traps or utterly amazing and changing between via a simple reload? FPS death caused by stuff trying to path to places it can't get to? Dwarves with rotten clothes thinking about getting new clothes all the time thus killing your FPS?).

[HungryHobo]

Ever heard of peer review?

What do you think I was talking about when I said "communication overhead".
The same goes for having to arse around with highly detailed requirements documents and all the other fun of working with a large group.

You're honestly trying to tell us that having someone else work on fixing the bugs or at the very least casting an informed eye over the code would cause more bugs? I can think of about a dozen bugs I could fix myself in this game without even having looked at the code yet

And thus you introduce even more bugs when the code you are absolutely sure couldn't cause an issue causes issues.
The most toxic problems come from code written by people who are utterly sure that nothing they've changed could cause a problem.

I've seen an entire billion dollar Fab taken down by someone screwing around with a piece of code in a way which they were absolutely positive could never cause a problem.

*looking* for bugs is fine.
But once you get more than one person dicking around with the code you introduce either extra bugs or extra communication overhead.

Given the scale of this game I think it's amazing it works as well as it does.

having multiple people work on code is perfectly fine as long as you plan it out well and don't expect to have your cake and eat it too but throwing extra coders at a large  project that's been in development for a long time already is a great way to create a clusterfuck.

[Malibu Stacey]

And thus you introduce even more bugs when the code you are absolutely sure couldn't cause an issue causes issues.
The most toxic problems come from code written by people who are utterly sure that nothing they've changed could cause a problem.

I've seen an entire billion dollar Fab taken down by someone screwing around with a piece of code in a way which they were absolutely positive could never cause a problem.

*looking* for bugs is fine.
But once you get more than one person dicking around with the code you introduce either extra bugs or extra communication overhead.

Given the scale of this game I think it's amazing it works as well as it does.

having multiple people work on code is perfectly fine as long as you plan it out well and don't expect to have your cake and eat it too but throwing extra coders at a large  project that's in been in development for a long time already is a great way to create a clusterfuck.

I've seen average software become very good to pretty amazing by the introduction of a few skilled people who know how to write very good code. Not only do these very good people bring their skill in software development but they also bring knowledge of good practices which will help everyone work better. Want examples in the games industry? See http://www.arcengames.com. AI War was already pretty amazing when it was only Chris working on it. Since Keith joined the team it's gotten even better. Here's the release notes for the latest version release (equivalent to the 40d -> 0.31.01 release). That took them exactly 3 months (4.021 came out 27th October 2010, 5.000 came out 27th January 2011).

For every strawman you create, I can counter it with an equal and opposing strawman.

Given the scale of this game I think it's amazing it works at all. The bug tracker has 1800+ open issues in it the majority of which have been in existence since 0.31.01 & large number of those pre-date the bug tracker its self as they were in 40d too. Playing it for any length of time you run into so many bugs that need worked around, features you either have to pretend don't exist or just turn off until eventually the bugs win & you quit out of boredom due to FPS death.

[HungryHobo]

For every strawman you create, I can counter it with an equal and opposing strawman.

I guess you're right then.
Adding more people to a large project in development doesn't slow it down further.
Fred Brooks is wrong.
The man-month is not mythical.
Throw coders at a problem and it will speed things up.

[Shrike]

I would certainly hire him a team!
MADE OF PERFECT CLONES OF HIMSELF.
MASSIVELY PARALLEL TOADY CODING.
So, we'd have Toady One, two, three...

[Taricus]

PERFECT!

[LemonFrosted]

For every strawman you create, I can counter it with an equal and opposing strawman.

I guess you're right then.
Adding more people to a large project in development doesn't slow it down further.
Fred Brooks is wrong.
The man-month is not mythical.
Throw coders at a problem and it will speed things up.

You're trying to pain it as all or nothing. Fred Brooks does not assume you're talking about a one man project where that one man is doing every single job in the office. While a lot of the process is linear, that's not to say that it's all linear. The best example would be all the business stuff and the architecture stuff which you would normally do in parallel. Brooks wasn't talking about a situation where the lead programmer needs to take a day off every week to be the project's accountant, he assumes that you're already in an environment with enough people that job specialization exists. You're basically trying to say that one-man-projects are the fastest possible development scenario because there's no communication overhead. That's stupid. Of course it isn't. Adding people causes temporary slowdown, this is fact. The problem Brooks was addressing was that management often saw fit to add people at a point in development where the period of temporary slowdown was equal to or greater than the remaining development time as is. In the total scope of what DF might eventually be you could ballpark that they're, what, 30% done? Less? I'm pretty sure that adding a couple people at this point wouldn't cause several years worth of slowdown.

[Malibu Stacey]

Exactly. There's a huge gulf of difference between a small team of a few coders & a massive team of hundreds of coders with management structures trying to organise everything.

Funnily enough my current job of 4 years+ is in a team of the former (20 or so code writing developers) where as my previous 2 jobs were in companies described by the latter. I also have quite a few friends, former colleagues & acquaintances in both types.

I guess I just must not know what I'm talking about. Some guy wrote a book from one perspective so that's all we can ever discuss because anyone else who actually lives & breathes this stuff clearly doesn't know as much as whats in some book written 25 years ago before anyone even thought seriously about things like Agile software development.........

[Naros]

Nice "Mythical Man-Month" quote there. 

My current software overlords, who hold me captive in a white, padded, and sound-proof code-monkey cage (complete with a window in the door so the zoo visitors can watch!), understand my true nature all too well.  They've used exactly that threat of adding "a couple more people just to 'help out'" to coerce me into finishing things faster than logical.  I won't say I hate them for it, because I want today's allotment of peanuts, but I also don't like being played like that.

Ha ha! That's brilliant.

I'd not spend it all on DF, though I love DF there's many things I love.
I don't gamble though so, I'll never have to worry about it..

[Sirdrake]

I would buy the new IBM watson supercomputer and have a pop cap of like 5000 and an embark area of 32x32

Spoiler (click to show/hide)

http://www.youtube.com/watch?v=dr7IxQeXr7g

[Vorthon]

I would buy the new IBM watson supercomputer and have a pop cap of like 5000 and an embark area of 32x32

Spoiler (click to show/hide)

http://www.youtube.com/watch?v=dr7IxQeXr7g

And you'd need Dwarf therapist on steroids just to micromanage that.