//

Development hell | Gwern@ | my notes

https://www.gwern.net/Anime-reviews#on-development-hell

Development hell is not universal. And it’s not intrinsic to creative work period, as we can contrast it with other areas like STEM. Everyone can name examples of development hell blighting fiction or games, but it’s much harder to name a scientific or technical or mathematical work which clearly suffered from a ‘development hell’; a software program might launch late and be beaten to a punch (Project Xanadu being an exception that prove the rule), and a mathematical proof might be unnecessarily delayed when it would have been adequate published beforehand (there are countless examples of interesting and publishable results in Gauss or Euler or Ramanujan’s notebooks, to give 3 famous examples of posthumous publications, which simply didn’t meet theirs, but others’, standards). A web browser or operating system given 5 years of development time may just barely be adequate; the same program after 10 years will be much better (modulo issues like bitrot/bitcreep).

Open process and git VC solves development hell.

In the Tao Teh Ching’s analogy, creating “is like cooking a small fish” (ie. if you poke it or move it much, the delicate meat will fall apart into mush).
Loss of novelty: many works are products of their time; what was interesting and exciting at the outset is long since obsolete a decade or two later. This can be cultural, or it can be technical.

T3 publishing solves this.

Loss of vision: ‘too many cooks spoil the broth’. A strong consistent esthetic vision and purpose characterizes the best works; it cannot be a bunch of short films made by different people and rammed together to take up 90 minutes. The more time that passes, the harder it is to coordinate each involved person as they come and go, and every change makes it more of a patchwork. The average of many good ideas may be a bad idea. After long enough, whatever was good about the original has been watered down or buried under a mountain of irrelevancies and mediocrities.

This happened to DCSS, as it grew obsolete and converged.

A loss of novelty may also induce the creator’s loss of vision. Too much time spent on a project blinds ones to its virtues and vices. One loses perspective or the ability to see it afresh; a ‘curse of expertise’ and the ‘illusion of transparency’ begin to set in, and the creative impulse degenerates into l’art pour l’art.

This explains my failure to document RIITR adequately before Treemind.

Loss of interest: closely related to the loss of vision is the need to ‘strike while the iron is hot’. A creative project thrives on a ferment of activity and interest from its creators, and the more collaborative it is, the more it depends on a little community. Films and games in particular are dependent on this: behind every auteur, there is a group of skilled collaborators freely playing with ideas and tricks and proposals, working 16-hours a day to make a vision a reality, with the auteur riding herd and selecting out the best. Many a perfect proposal has started off as an inside joke, or technical experiment, or random comment by a janitor, only to take over. When no one involved cares, when the leader takes every opportunity to go off to work on other projects, when people are punching the clock 9–5PM, the work may be professional, but it will never be perfect. Mere money and time cannot replace love or esprit de corps.

Altrugenics has largely lost this momentum, but in exchange, Cyborganize is building it.

Another way for development hell being a selection effect would be regression to the mean. Regression should never be neglected, and it seems like at least some of this may be just regression to the mean; as development hell is rarely possible with first works (who have no reputation nor money from earlier successes), if someone makes an extremely successful film and becomes overnight famous, their second film should be expected to be considerably worse; a second film entering development hell may simply reflect everyone’s awareness that it’s just not good yet, and a way of delaying the reckoning or hoping to pull it off.
Of these reasons, I think #5, loss of feedback, and #2, loss of vision, are the key ones leading to development hell being so much worse in creative fiction/arts than in more technical STEM-like areas.

Both affected DCSS.

Intellectual rot can be kept in check by reality. In STEM areas, while there are still problems where ‘too many cooks spoils the broth’ applies (leading to observations like the second-system effect), one is heavily constrained by Nature. When there are real world consequences, hard requirements, demanding users, or formal rigor, unproductive navel-gazing and architecture astronauting are less likely. It is much harder to gradually degenerate when the problem itself continually provides feedback: changes to such a thing either do or do not work to a much greater extent than rewatching one’s edits to the rushes of a horror film for the one hundredth time clearly does or does not work.

Data-driven decisionmaking and betting are key to DCSS' future.  Must be based on elite competitive play, not lazy median player.

Publish At: Author:Leo Littlebook

Read more posts by this author

comments powered by Disqus