I had a thought.

REpresentational State Transfer is a very cool concept, especially if you want to build a very read heavy API. But it suffers from exactly the same problems as a lot of other technologies once two or more actors want to do change the same piece of data at the same time. There are no transactions and there are no clues as to what the client thought the data was when they changed it. What are you supposed to do?

It also has legacy problems in terms of support for the more exotic verbs “PUT”, “DELETE” have wider support, but you can still have problems with legacy browsers and firewalls.

This left me asking myself some questions.

Knockout is currently my favourite way of using ECMAScript at large. It essentially allows you to outsource event management and focus on business logic and views, but at a cost: events go in, and if they don’t come out in the way you expected you are screwed.

How do Apple’s .pkg installation files work?

Today I learned the answer to a couple of questions I didn’t realize I had:

Why are you prompted to install to a volume, not a directory?

Can I really keep applications outside of the /Applications directory?

I’ve been on both sides of the Agile transformation equation, both transformed and the transformer. Over the years I have seen a couple of anti-patterns in engagements that should be avoided.

Being an ex-Guardianista Conway’s Game of Life has a special place in my heart. The problem is simple enough that you can express it in 6 or 7 cards and devious enough that two developers rarely come up with the same solution twice. It can be easily test driven and, in Java, the naive approach takes about and hour and a half to complete and usually spans three to five classes.

It is a neat problem to put a language through whilst you’re learning it.

Things I really liked about Clojure:

• Leiningen : the best build tool I’ve ever user. Easy to configure. Easy to find help on.
• Midje: lovely little testing framework that doesn’t feel like it is getting in your way
• Being able to make my solution parallel simply by making map -> pmap (not that it helped performance)

Things that I learned to like:

• Immutable objects: I thought I was pretty good at making my methods idempotent in OO code. I was surprised at how much I had to shift my thinking to get it to work for real.
• Functional style: I really though this would be a breeze coming from Ruby / Python / Javascript, but functions without objects are completely different. What really surprised me is that loosing the structure and state embodied in objects actually made the solution feel lighter and me for more powerful.
• REPL: Immutable objects and strict scoping for values complicates the REPL experience. But it is still very nice to have a REPL, vs Java / C#.
• (): They really do melt away.

Things that I didn’t like:

• Clojure start-up time: it really is a second more than the usual JVM start up, enough to affect the frequency of running the tests compared to python or ruby.
• Debugging: I tried and failed to use trace and although you get some feed back from the exceptions, it was not as laser guided as Java or C#.
• Learning curve: Learning new languages is fun for me. I’ve been programming since I was five years old in Logo and Basic. I learned Java and Haskell at University and I’ve been programming professionally in Java, C#, Python and Ruby for the last 8 years. Clojure was the toughest of all of them. It was like learning to code from scratch all over again.
• Readability: Clojure lends itself to a terse style of programming and I can imagine finding it hard to read my own code in a couple of weeks. Python and Java have it beat.
• IDE Support: Syntax highlighting and paren matching is about as good as it gets. That is plenty though. I’ve heard good things from Emacs users about Clojure support, but have no experience myself.

I’ve come away from this experience a lot more positively than I expected too. Clojure is a language that has opened my eyes to complete different way of solving problems, and I liked it. There is a maturity in the ecosystem that is sorely missing from C#, Python and Scala in the form of leiningen which is comparable to Bundler and significantly better than Maven.

My biggest concern is that I have no idea how I would sell Clojure on a project. It is hard enough to find developers who can work in Java and C#, and harder still to find Ruby developers. I’m not sure I could apply the approach that the Guardian does for Scala and hire talented Java developers and then train them in Clojure. I relied far more on my Computer Science degree to get me through the Kata than my Java experience. Scala advantage here is being able to write Scala like Java with closures and type inference. If universities started to teach Lisps with the same passion as they do C style languages this would be less of a problem.

There are some problem spaces where Clojure looks really attractive. Expert systems written using core.logic look very interesting, but they are competing head on with Drools which has a significantly lower cognitive cost of entry even if Clojure definitely has a syntax advantage in that space.

Concurrency is another area where Clojure makes excellent choices but my experience tells me that you really need close to a hundred cores to make concurrency pay because of synchronization costs. If you need concurrency to deal with IO delay then the Disruptor pattern or just an event loop provide much better bang for buck and even languages with global interpreter locks (GIL) like Ruby and Python are more than adequate for that. If you have an embarrassingly parallel computation problem Clojure may get you to a solution faster. Projects like Parallella might also help prove that multi-core is the near future. If you can genuinely out perform a $1000 server with $99 of arm chips with 16 co-processors that is a compelling reason to look at Clojure / Go / Scala.

DSLs are another area where Clojure excels. Macros mean you can re-write the syntax in the language with no runtime penalty. I’m just not sure that DSLs are compelling on their own and I’ve seen enough bad DSLs in Ruby to know that they are no panacea.

So that is my view on Clojure. It is a fantastic language that is looking for a solution that can justify its learning curve.

I was introduced to Unit Testing back in 2007 on my first agile gig. At that point Unit tests were defined to me as ‘tests that proved individual units of code’. Database connections were a smell, but not forbidden; mocks, stubs were actively encouraged. The closer we got to 100% coverage the better, but we did at least have the sense to not test the language, so no constructor or property testing.

Functional tests were then defined to me as ‘tests the prove that individual units work together’. This usually meant writing unit tests, but with spring providing you with real objects rather than mocks and it was generally accepted that a real database / service would be used. This was often an after thought, as we already had close to 100% unit coverage. There purpose was to catch bugs that only occurred in the interaction of objects that would otherwise have only been tested in isolation. The functional suite was a little light, predominantly because it was never really clear if functional tests were really just unit tests.

Integration tests were then described as ‘proving that the whole thing works together’, and were originally HTTPUnit tests, until we ‘advanced’ towards selenium. They were slow and unreliable. The build would break for environmental reasons so often that it was a surprise when they broke for real.

Despite this I was sold, at least I was sold on Unit testing. It just made my code better and gave me a way of thinking about the problem before I thought about the solution, but there were a few problems.

• Slow tests: Unit tests got slow fast. This boiled down to
  • Database calls: you can perform 100 unit tests in the time it takes to make one database call
  • Over mocking / stubbing: reflection is 10-100 times slower than a normal function call and as test code is only run once the most VMs won’t optimize it away.
• Writing test code often takes a lot longer than writing the production code.
• Over testing:
  • having to change tests in the unit, functional and integration tests
  • having to change five unit tests for one change.

Five years on and my styles have changed. This is how I see automated testing now.

If there is one practice guaranteed to reduce the number of bugs in a system it is desk checking.

The process should look something like this:

1. Developer believes they have finished a story
2. Developer integrates with the latest version of the code
3. Developer runs automated tests
4. Developer asks the QA to ‘Desk Check’ their code
5. QA runs a quick, manual smoke test that puts the system through its paces
6. If any errors are found, Developer and QA discuss mechanisms for automating that testing at a unit or functional level.
7. Developer implements those tests, fixes problem and repeats.

Up until step four this process should be familiar to all developers. In practice, steps four through six rarely take more than five minutes, so if it catches just a single bug it can save the project an hour of developer context switching. There are other subtle benefits as well. Letting developers see how you test can help reduce the time it takes to test even further, it may even help them to identify other problems.

All parties involved in defect resolution agree that early diagnosis and resolution of bugs is good for everyone, but ‘Desk Checking’ is often met with resistance from both QA and Developers.

I’ve experienced complaints from QA that desk checking interferes with normal testing, but really the attitude should be that ‘normal testing’ is the filler between desk checks, they are that effective.

It is also a little confrontational. Developers can react badly to having their weaknesses exposed so publicly and personally. This is just an unhealthy attitude on the part of the developer and should be considered a smell by their management. Remember, it may not be productive in the long run, but making a developer cry is a QA rite of passage.

We have all heard the rhetoric that ‘Quality’ is everyones responsibility, but ‘Quality’ is not a metric that is easy to define. That is why we have QA. To my mind QA is one of the most maligned and under-rated roles in software development, but it is probably the most important of all of them.

It doesn’t matter how reliable or clever your product is if it ‘sucks’.

I have argued that Steve Jobs may have been a marvelous raconteur but that his real talent was quality assurance. His public appearance may have been full of rhetoric and bluff, but for the most part, the ‘reality distortion field’ experience converted millions of people to iPod and iPhone over a period of years, with a market that grew release after release and that is a hallmark of quality.

I don’t believe Mr. Jobs followed the evolution that I am about to outline at least not professionally, a successful start up will do that to you. In any case, that requires a mixture of luck and foresight which isn’t a pre-requisite for becoming a QA. But I do believe that, if nurtured correctly, you can grow your own QA.