Craft Conference Day 3
Today we arrived a little bit later, because Hungarian breakfast just doesn’t take long. It’s just eating a sweet pastry thing, drink some coffee and you’re good to go. I was really yearning to eat something healthy by now. I walked by the O’Reilly stand and spotted “Explore it!” by Elisabeth Hendrickson. This is one of the books I still wanted to have so it was great to pick it up with 40% discount. The lady operating the stand was really fun to talk to!
Then we headed off to see the first keynote of the day.
Chad Fowler – McDonalds, Six Sigma, and Offshore Outsourcing: Unexpected Sources of Insight
The story of this guy was pretty cool. He went from being a professional saxophonist to programmer. Why on earth would you want to do that?? Well, I thought his story was pretty convincing and I could really relate (tried to pursue my own professional music career before switching to IT). He was just tired of playing the same songs on his saxophone over and over and went on a journey to do something else. He ended up being a passionate programmer and in his talk was trying to express what he considers to be the craft of programming.
When we try to master programming we try to master this thing we call ‘building high quality software’. But what do we mean? What is quality? Is it even possible to define? In fact, it’s a dynamic concept. You and I may differ on our perspective of quality. He then showed us a graph about Art and Commodity.
Art <————————craft ————————> Commodity
Form Function
Craft is also hard to define (surprise!). It also depends on who you ask do describe it. Chad Fowler thinks it’s somewhere in the middle of art and commodity. When you are crafting software you not only make it function well, you also make sure you form it well. That maybe delivers higher quality.
There is a huge problem though. Quality is very hard to measure. We try to do it with code coverage and what not, but that only answers a part of the question. Chad then went on to describe the Six Sigma model. He loathed it at first, but after some years he saw value in it. Six Sigma makes quality assurance a non-emotional thing.
I scribbled some notes here, because I personally think it is alright to feel emotional about quality. Aside from assuring quality as scientific as possible, it is also really important to let the business feel confident about quality of the product. That is something you cannot measure, you have to build that trust.
Anyway, I do agree with Chad that your basic quality assurance should be as consistent as possible. Therefore, Six Sigma might be a way to do it (partly).
Another quote I scribbled down was “We are no better than others; we just have different motivations.” That certainly is true about quality!
This keynote was great to start the day with. You could tell Chad was having fun talking and his story was a compelling one. He also talked about offshoring, but I didn’t make notes about that. My memory is already having trouble remembering stuff from the conference. But hey, you could always see the talk again online! Awesome that they taped everything and made it available for everyone who’s interested.
Responsibly maximizing craftsmanship in software engineering – Theo Schlossnagle
We stayed in the main hall because this talk seemed great on paper. And geez, it blew me away. This guy was just saying it the way it is.
First of all: most software sucks and craftsmanship is a paradox. Well hello everyone, wake up!
It’s almost impossible to write good software, is what he claimed. When you type something in google it’s almost magical what happens in just a second. Almost no one understands that from a to z. (Indeed, I sometimes think: how is it possible that this piece of software is still working…..Windows XP for example, or government websites)
Then, to make things worse, specifications are also hard to write. So, you want to make good software but you’re already starting wrong. That’s not good ey?
And as of quality: people perceive that concept different from person to person. Same thing what Chad was saying in the keynote.
So….we need change!
Laziness is not a virtue. Lots of programmers describe themselves as lazy and are proud of it. “I don’t like doing things twice so I automate it”. They’d sometimes rather misuse a tool than write one of their own. Theo says: code your own. You might even learn a thing or two.
Bigger code: refactoring effort is not just lineair. The effort goes up and up when the code gets bigger and more complex. The learning curve is enormous. Adding new features is very difficult, because the code is so complex. They says: keep your components small. In that way, if one component is impossible to refactor because the code is shit you can just throw it out and rewrite it.
The crowd was cheering when he said “learn to hit a fucking deadline”. I TOTALLY agree. How often have I seen this in my own projects….too often. Ask a developer how long a certain task is and he will say ‘I will have it completed today’. More often than not I was happy if I could test it within a week. For testers, such as myself, it is sooooooo frustrating to constantly be disappointed because someone cannot estimate how long it will take to finish a task. High five for Theo! If you KNOW that you often underestimate the effort of a task why don’t you simply double your estimate? You can avoid a lot of sad faces.
I also strongly agreed when he was talking about social values. Sometimes you come across a team member who prefers to listen to music all day; just being alone in his bubble. And then they look irritated when you want to askt hem a quesiton. How annoying is that! That person misses a lot of important stuff. And hey, it’s nice to talk to your colleagues too. In my team we have a ‘rule’ for that. You want to listen to music? Sure, just put your earbuds in only one ear, so you can still hear important stuff around you. You need some focus? Then plug yourself in and code away without being bothered. I do that myself for 30 minutes – 1 hour a day. It’s a challenge to focus at work when so much is happening around you, I completely acknowledge that. But ignoring your team mates is not really an option if you ask me.
I’d strongly recommend to watch Theo’s talk on the website, because he had so much more to say than what I write down here. Watch all the talks here: http://craft-conf.com/2014/
Find the Right Abstraction Level for Your Tests – Gerard Meszaros
Comic Sans in a presentation, really?? I’m not a huge typography nerd, but comic sans should die. It was all over his powerpoint. His powerpoint was pretty chaotic to begin with and that was a bit of a problem for me. I just didn’t know where to look and it was annoying me. I always keep my own slides as empty as possible so this was almost the opposite of what I value in a presentation. That being said, the information given was very good!
“Test craftsmanship is to avoid the huge cost of automation”. That’s one way to look at it, and partly true. It’s just one aspect of test craftsmanship, but I was glad there was finally a talk on my own profession.
Gerard really focussed on “what can you leave out of the test”. Make it short, less detailed, test specific behaviour and test thoroughly. Basically, it was clean code for test automation.
He showed us some great examples and I can really use that stuff in my own project, where I am struggling with exactly this issue. I now know how to refactor some of my testcode and make it more readable and understandable.
Valuable talk, good to watch if you are having issues with your automated tests being brittle or hard to understand.
More to come…
Comments ()