
TDD leads to an architectural meltdown around iteration three - fogus
http://beust.com/weblog/2008/03/03/tdd-leads-to-an-architectural-meltdown-around-iteration-three/
======
chipsy
The mention of fear-driven coding strikes me as possibly more important than
the process and architecture discussion. The whole concept that your emotions
drive the focus of the code you write seems very true to me.

As a beginner and student coder, fear struck me a _lot_. I read a lot of the
literature, I saw all the "don't do this" guides and blog posts, and so I was
always concerned and hesitant about whether the code I wrote would be a good
foundation for whatever came next - never mind the fact that my projects were
so often left unfinished.

I also wanted to work mostly in high level languages(TI-BASIC, Python, etc.)
while wrangling as much graphics performance as possible out of them - before
I had my full featureset in place - which led me to micro-optimize those
languages past the point of maintainability, with inlining and caching tricks
all over the place. All of this was a result of fear of the classes of bugs
one gets by working with the lower-level abstractions - even though I
understood pointers and memory management competently enough.

In the end, I've only gotten over these hangups by trying all the methods and
seeing which ones slow me down or lead to meltdowns in practice. A lot of it
turns out to be domain-specific - so e.g. I could tell you right now that
doing string manipulation in C is likely to cause tons of pain, and writing
the core loops of a 3D renderer in Python will make it unbearably slow. But
there are all sorts of problems where I have no real answer, and will have to
resort to failing fast to wrap my head around the problem.

