And that’s not just some long-haired hippie’s opinion. Wednesday night we had a mini-geek night at work and we got onto the topic of whether or not (code) magic was good or bad. It was a great conversation and because Ade doesn’t have a blog (when are you going to get one?), I thought I’d write about it.
I struggled at first to work out what we meant by ‘magic’ and we somehow concluded at some point, for it to be ‘the unknown’. For instance, when you plug stuff into the Rails framework, there’s some sort of ‘magic’ going on to hook it all up. The focus of the discussion was really about whether or not we thought magic was good or not.
To actually substitute our other meaning, ‘the unknown’ for magic makes the question a very strange one – ‘Is the unknown good or bad?’
My attempt at answering this question was that the concept of magic is not good or bad, but whether or not the attempt at magic is good or bad. In general, I personally like magic because it makes my life easier. I shouldn’t have to understand how the compiler, for instance, turns code I write into bytecode every time I want to do something. I like the fact that it just works and that’s how it is. The abstraction or illusion holds true every time I run it and I can depend on it to work day in and out.
I consider magic good if it doesn’t require you to understand it. Bad magic on the other hand is bad because it forces you to work out how it works, and that need, let alone the experience, is generally traumatising. It’s like a magician’s illusion failing us because you have to go behind the scenes to understand all the little tricks that made it work. What can make it worse is if it is difficult to investigate how it works such as the source code not being available, or horrible code that’s hard to read, or an abstraction that just doesn’t work.
All of this is circumstantial and really depends on how well the magic was built. If the magic works all the time (and generally that’s because the abstraction is sound) and it does all the things that you need, then I think it’s a good thing.
One of the benefits you get with consulting is that you get to see a variety of applications, processes, and in agile projects, different build pipelines. I take the developer loop very seriously, because how quickly you can get feedback determines how quickly you get serious things done. Different testing strategies are an important way of improving the amounts of feedback (as long as you can still write meaningful tests). Another technique is the ease with which you can configure various libraries, integration points and environments. Even splitting the build into various stages where failing earlier is more appropriate can help you get better feedback.
The ultimate feedback loop I’ve seen in Java is the “change-compile-run test” loop. Anything more and you will decrease your feedback cycle and adversely affect how fast you can develop. Anything less than this is unacceptable – skipping the “run test” stage doesn’t do anything to validate that what you wrote actually works. On a side note, in an interpreted language, the loop is even tighter, simply being “change-run test”. 
I started at a new client yesterday, and we had a great conversation on my thoughts about working overtime. Anyone who has worked with me in the past knows that as a principle, I heavily dislike working overtime. I think I provided some pretty good reasons and thought I’d write about it. 
