Bay 12 Games Forum

Unfortunately that isn't the whole story of how it works -- even if the whole story is nuanced and may admit of pros and cons, programming jobs are never as simple as somebody else making the program happen on their time instead of yours based on instructions that take less time than coding. Even the programmers who are also the designers (Toady and Threetoe) are constantly revising the design based not just on ideas, but on what they find feasible to do at the present time in coding. Furthermore, even they often make bugs that affect the gameplay and may not be isolated for years (no joke: there's a recently figured out bug that 9/10 of all creatures will not grow larger while at the fortress, and for years all we knew was that militias and especially hundreds of fortress-bred war dogs seem inexplicably puny). Think of it this way: if you found a programmer who was ninety-nine percent perfect, then asked him to write a hundred thousand lines of code, how many lines of code on average will contain a bug? In the corporate world all sorts of systems have to be put in place to deal with this one simple problem of programmer fallibility, entire frameworks of testing and user agreements and project management and oversight into hiring more developers and the list goes on -- and gets wilder the farther you get from directly influencing the quality of the code, until at the extreme the entire I.T. department could be reorganized on the theory that some improvements could be made to the system if only the entire structure was different. (If you want evidence of this, I suggest talking to anyone you happen to know who works in a corporate environment. You don't have to take my word for it.) Obviously, Toady and Threetoe aren't exactly set up to run a whole organization with the kind of frameworks that could do that (or attempt to do that, as the case may be), and it's understandable if they wouldn't want to be for one reason or another. But more importantly it's not, in any case, a matter of sending the coding off to a programmer and having removed that work from Toady and Threetoe, it's a matter of exchanging one form of work -- coding it themselves, with its pros and cons -- for another -- making sure that the guy who is coding it not only knows what to do but manages to do it. They're lucky enough that for certain select parts of the program they've been able to have someone they know pitch in and actually be helpful (the graphics, in particular); it's quite unlikely they'd have the same success with anything broader or more intricate within the game, not because of anything that would need proving about the code's complexity or the measurable aspects of the job but simply because sending the work of coding to someone else doesn't actually make it go away, not without much larger frameworks in place to support such separation of designer and implementer while still getting the finished product evaluated by the designers easily and corrected if necessary in a timely fashion.

Sorry about the Wall o' Text; I have a "talent" for not explaining things briefly... and this is a pet peeve of mine based on professional experience in I.T. I should clarify that more programmers on a project *can* sometimes make it more manageable if they're all sufficiently good *and* all understand it in and out, but with a life's-work project like Dwarf Fortress the kind of understanding that would have to be opened up to have that in and out thoroughness is arguably more a personal than a professional decision. Without additional project members being closely tied to the project and understanding it almost as well as the designer, you run back into the situation that the designer would still have to deal with the work done by the coder in place of doing the coding himself, because the only thing that would allow the other developers to correct and improve their own work is if they truly understood the goal it was supposed to meet and weren't simply told to "do X".