Looking at the agenda, I knew exactly which talks I wanted to attend on last day of the conference.
Integrating JVM languages
by
Venkat Subramaniam
Once again, Venkat gave a very entertaining talk, this time about the integration of various languages running on Java Virtual Machine (Java,Groovy,Scala,JRuby) and the problems one can get into when trying to do it. In general, the integration is quite smooth, but there are some edge cases when the solution is not really trivial. From what I've seen Groovy seems to have the most smooth integration, but things don't look bad with Scala or JRuby. While I didn't gained any immediately enlightening knowledge I got a good introduction into the subject and now I know that it's not that hard to do and knowing a few languages that run on JVM one can pick the one most suitable for the problem at hand and don't suffer too much when integrating it with the rest of the application. That's cool, especially that after Venkat's talk about Scala on the 2nd day our manager gave us green light to use it in our project when we learn the language a bit.
MongoDB : Scaling web applications
by
Ken Sipe
This one was another eye-opener, not really for me - because I investigated the topic a bit before - but for some of my colleagues for sure. My boss got quite excited about it as he recognized immediately a part of our system that could be easily implemented using MongoDB as storage (and which has been in development for about 2 years now and still very far from being perfect or even production-ready). Ken shown us an example of real web site with Mongo storing it's data. He offered a few useful bits of advice, like modelling the documents based on the specific use cases, so that there's no need to fetch multiple documents for a single thing. He mentioned ways to scale Mongo and to fine tune its performance. Talk was very informative and as a result I was asked to create a proof-of-concept for replacing the mentioned part of our system with Mongo-based implementation (more on that in another post).
The Three Laws of Test Driven Development
by
Uncle Bob
I guess I was not the only one really looking forward to this talk. That was the very first time I could meet Uncle Bob live (and I regret I didn't have any of his books for him to sign). As I have read a lot of Uncle's posts and watched a few presentations as well I knew what I could expect, but even then his live performance was an awesome thing to watch, listen & learn from. I guess that almost every phrase could be used as a really good quote.
Introduction of TDD began with some sad numbers, as only about 5% of the industry is doing TDD. This number is however improving rapidly, and in a few years we can expect it to be much better.
Uncle Bob dealt quickly with the myth that developers don't have time to write tests/do TDD. As he said, it's childish to think that we have to make a mess to be quick, even if this mess is going to slow us down in the longer run. When mess in the code base grows, more effort is put into moving it from place to place instead of developing new features. That's not the situation we want to have in our projects as it often ends with a redesign of the whole systems, made by the experienced guys (the "Tiger" team) - the same who made the whole mess in the first place. Of course, team doing the redesign has to be quick to catch up with the feature set of the system they are going to replace. And to be quick, they need to make some mess of course... See the pattern?
Instead of falling into the trap of the big redesign, we should rather concentrate on clearing thes mess one little bit at a time. That's of course the famous Boy Scout Rule that Uncle Bob often mentions. Each time we touch our code, we should make some improvements. Even small ones. Even very small ones. And of course, when writing new code, we should avoid creating mess. Don't even dare to think to yourself: "I'll fix it later". Later does not exist. We all know it.
"Bad mgmt can be suffered through but the bad code is the anchor that is bringing the company down"
Unfortunately, we are often reluctant to clean up the mess we find in the code we read. We think if we clean it and break it in the process we'll be responsible for it from now on. Or we might be afraid of touching it because we've got no idea what will happen (break) if we do. As Uncle Bob said:
"We have created the monster and now the monster rules us"
That's unfortunately sad reality for many (most?) software projects. As professionals we should have control over our creations. Our software can't just work (any idiot can do that). It must be continuously flexible, easy to maintain & modify at any point in its life.
"You don't want to be good at debugging. It's not a skill to be desired"
"You don't want to spend time debugging. You want to spend time not bugging"
Debugging is hard. And takes a lot of time. The good news is - we can avoid it. Maybe not 100% but most of the time. How? Use the Force, Luke. I mean, use TDD. With TDD done well (that's the trick - you have to do it well otherwise your code will suck as much as it would if you haven't. But to do it well you have to practice it!).
Additional benefits we get when doing TDD are the formal design docs (yup, your tests), nice & decoupled code. And the possibility to refactor with fear.
Uncle Bob also said more than a few words about fast tests. The suite of unit tests of FitNesse (1892 unit tests) is running on his Mac in under 50s. That's pretty awesome and shows how short feedback loop
unit tests give. In our project a suite of 700 tests runs for a few minutes (~3) - most of them are functional tests and it's not very useful for doing TDD. And we have to change our mindset regarding such tests - there's no reason for acceptance tests to be slow. They even can't be slow. It's our job to make them blazing fast. There's no excuse for it.
"If you want control over your code you'd better get yourself a suite of tests"
Another important thing is the trust you are willing to put into your test suite. It's like jumping out of a plane with a parachute - you'd better now have any holes in it. Software can be extremely easily broken, just flip a single bit and it's done (unlike your brain which can loose a couple of thousands of cells in a single drinking session and not be affected by this loss). You need a really good suite of tests, one that you can trust your life to. When it runs and passes, you should be convinced that your software works. If you're not and have to check it manually - what good are your tests for?
And for the end, a few Questions & Answers, which made the whole audience laugh:
Q: But we have a testing department, I don't have to write tests!
A: Screw you!
Q: What about refactorings?
A: It's a good idea to refactor your code. Next question"
Q: How you start TDD culture in company that doesn't have it?
A: You start shooting people at random. Don't get your hopes high regarding developing a TDD culture in your company. And remember - you can always change your organization or change your organization.
Code Craft
by
Nat Schutta
Next talk was very nice, going back to the basics - good code, bad code and how to improve it (tip: write less of it, less is more). While nothing earth-shattering, it was a real pleasure to listen to a good speaker, got reminded of many things that we might not think about too often. We got reminded to simplify the code, to talk to each other about it (most of us prefers to write code, not to read it, and it's critical to read code) - but we need to remember that we have to be critical of the code, not the people.
Nat also warned us against thinking too much about code reuse - it should be a byproduct, not a rationale (but too often I participate in meetings when we talk about reusing the code that is not even written yet!).
Nat also touched the topic of tests - we should treat them the same way we treat production code and if a developer is not writing them he's not really doing his job.
And the last advice was where to start improving code - we should let the feat guide us. We should start where the code is really scary. That's where the biggest mess is, just begging us to get it cleaned up.
Demanding Professionalism
by
Uncle Bob
I was really sad when this last keynote started, as I knew that I will have to leave early to catch my train back home.
The talk started with a question what is the
software crisis? As Uncle Bob put it:
It's so hard to get the damn software done right
One of the major problems is the lack of professionalism in our industry. We see bugs as normal thing that happens rather than "OMG A BUG!". And we live in an illusion that there's no demand for professionalism in software. But thinking about it - how else are we going to deliver features fast, if not by being professional and carefully crafting software?
There's an analogy often made, that building software is a bit like creating buildings. But in fact it's not - a normal architect creates the plans for the building because it's damn expensive to make changes after you started to lay the bricks down. In software, it's cheap so there's no point in having big design up-front. We've got to remember that we're not the masons - our code is not the product, it's the specification the compiler uses to build the product. We're more like architects, preparing plans for the compiler to follow.
Unfortunately, changing your design often works only if the build step is cheap. If we make it expensive (for example long - with slow builds!) the cost of building increases and we have to do more up-front planning. Therefore it's our duty as developers to keep the builds short, so that they don't get in our way when you want to change our design. We cannot submit to the idea that build just takes that much time...
... and unfortunately this is where 33rd degree conference ended for me. I left the presentation and went back home, with 'REST in practice' book I bought on the O'Reilly stand (James Lewis recommended this book and I must admit that it's a really good read).
I'm looking forward to coming back for the next edition of 33rd degree, if it will be possible. In the meantime, I'll probably join
Confitura conference in Warsaw, in June.
