dpJudas wrote:Also countless books out there selling magical solutions that they claim will fix it all - i.e. test driven development ("if you write the test first then you understand the problem space completely!").
Don't start me. I've heard this advice, too, but the end is mostly that the initially written tests are worthless because they never cover the entire scenario. Things always turn out more complicated than expected.
For what it's worth, test driven development seems to be an inevitable consequence of using 'high-level' languages which have (d)evolved to the point where the code cannot be trusted implicitly anymore.
Tests are useful where large amounts of data need to generate a fixed and immutable output, but they are not the metric by which development should be measured.
dpJudas wrote:Building temporary support code is often all worth the time doing so, even if you throw it away in the end. When I did the JIT the first task was to figure out how to only compile a subset of the functions. The code that analyzed and decided if a function can be JIT'ed is now gone because it can compile it all, but it was critical in the early stages of that project.
I did the same when converting the engine to floating point. The first thing I did was writing an entire support library of access functions to the common data structures, so I could then convert the fixed point code one small piece at a time - and most importantly TEST it one piece at a time. All those support functions were later removed again because their only purpose was to aid the transition.
The main reason Randi's first attempt at floatification many years earlier failed was that during the transition the engine had been in an uncompilable state for a long period of time and in the end all the small problems that accumulated presented an insurmountable obstacle.
