Last Friday I attended the “Software Craftsmanship and Testing” conference. I said “last Friday” because it lasted only one day, unlike the typical 3 days format (including night stays)… but for me it was just enough, I cannot really afford the extended versions. This event brought together about 50 folks with all possible backgrounds – developers .net, Java, JS, but also devops people… really, everything. The “unconference” format meant at the beginning whoever wanted to propose topics did so by placing a note on the schedule table, and explained in a few words what his discussion topic is. There were 8 “round tables” and 6 time slots, some technical some just discussions and as I deliberately decided to leave my laptop home my sessions were less “hands on”.
(Image via @ixchelruiz on Twitter)
Thinking I hesitated even the same morning, thinking whether it’s going to be worthy or not… but no, the discussions were more than captivating and some even heated 🙂 Here are my day’s notes, barely brushed and edited for a better understanding.
Get rid of your test environment
The initial challenge was why don’t everybody just throw code in production and sort it out later like NetFlix does. It became quickly obvious that not everybody is NetFlix and financial companies (and not only) cannot afford letting users to test their code. With this in mind, the discussion shifted gradually to best practices about deploying, how to integrate DevOps in team (or only teach the skills and build the respective production line). Blue/green production deployments seem still the best approach – too bad many customers are too cheap to allow this (or maybe we should push it more). I remembered here an old fight of mine regarding blue/green and how a contract can block one from actually using the best technical solution…
REST API testing
There seem to be some libraries to help you run test code against the REST interface – like REST-Assured in Java. But… why would you test on the API level at all?!? Once your business and application code is properly tested with unit and integration tests, testing on the API level will not bring any extra value. Unless of course you have your integration testing over the REST API, then it’s fine.
The “clean architecture” is the one you can explain without twisting your tongue (hint: rubber duck debugging). Should the application architecture focus on the technical solution or on the business domain? As architecture is meant to communicate also with the business it can be only focused on the domain, thus a certain business knowledge is required from the architect. Actually, some business knowledge would be required from every developer, making the role of the “architect” less and less important. At this point everybody agreed the “powerpoint architect” mandating technical components but doing no coding is a useless beast. This was obvious.
Efficient frontend development
Testing-first and legacy code
So what to do, if I create great testable code with a testing-first approach, but the code runs like 30 times slower than the legacy it’s supposed to replace? The initiator considered abandoning his test-driven approach and just hack around existing code. But… that’s exactly how technical debt gets cultivated, by hacking around things one doesn’t understand. So the only way is to keep the existing successful but slow test and code (a big one, testing a big piece of “black box” code) and remember the 3 steps of TDD: test, code, refactor. Now it’s refactoring time, for instance by trying to understand and extract piece by piece units of code (plus creating for them unit test) until the original big test is just an integration test for all these fresh small units. For refactoring hints there was recommended Martin Fowler’s book about dealing with legacy code. How much this correct approach will cost, is another issue…
Nature of software development
Projects mostly fail, and even agile doesn’t change that but only makes failure come in small and accepted bites. Also agile is not an answer for everything, especially when you’re bound to annual financial appraisals. Expectations from all sides are skewed because everybody uses terms from the house builders world – like software architect, build process… However, house builders benefit from millennia long experience, they have the physics and theory sorted out and not changing. A new house brings very minor improvements and one can choose projects from a catalogue even, plus the customers already have an idea about cost range. Stuff works quite similar in the car business – new cars have only minimal innovation and build a lot on reuse. In software however, almost every project is research job. Framework, infrastructure, possibilities change so quick and is ways so incompatible, that there’s no way to achieve the same level of modularity and reuse like in these other industries. So we’re doomed, unless everybody understands this – both developers and users. Basically: how can we get rid of the wrong building houses analogy?
Well, this was the day which ended obviously with a couple of beers and for others even a pub evening. I’m sure I will come back next year – unless it’ll be in the extended (regular) format – and I will recommend it warmly everybody. A big thank you to the organizers (and sponsors of course) and see you then!