For me it’s the first day of the conference, but some people already attended a workshop on wednesday. I was so curious how good the venue could be, because my last conference experience was dreadful. That had to do with the acoustics of the venue, there was echo everywhere and that killed all the pleasure, really. However, the Balna venue is fantastic! It is beautiful, spacious and professionally set up.
We were about the first ones to arrive and could enjoy walking around virtually alone. The breakfast was typical Hungarian, I guess. Lots of sweets. I don’t really care, as long as there is coffee available.
Then we were in the main hall right on time, but I’ve also learned that things don’t start exactly on time here. And, although I see why the sponsors must get their pitching time, it was a bit tedious to listen to the (mostly unprepared) talks.
I did find out that only 4% of the visitors of this conference is female and that saddens me deeply. They want to improve that next year, but apart from giving women free entrance I don’t know how. We women are just a real minority in the IT business 🙁
Keynote: Programming, Only Better by Bodil Stokke
Hah, this was a very funny keynote. Firstly because of the pony-covered presentation, but also because of the slightly cynical (female!!) presenter. I did learn some valuable stuff here and mainly got depressed about how I, as a tester, can keep up with the many coding mistakes that can be made. The main problems are in: state, control and code volume.
If you test one state of the program, you cannot assume it will work correctly in other states. The solution offered was ‘generative testing’ and I’m really going to explore this option in my own project. Bodil showed in Java how this could go wrong and it was shockingly easy to produce some crappy code that would succeed in one state and fail in another.
Control: the flow in which the program is executed. Here’s the horror of GOTO, nested IF statements and that sort of thing. Also, in some languages like Javascript, flow can become a real problem if it is coded badly. How can you test when you don’t know the order in which the program is executed? This brings up a question in my head: does the tester have to know the order in which the code is executed? I don’t think every tester knows exactly how code is executed….and is that bad? The developer should know, I think. And if code is bad it should be changed so it is clear. I think code review is very important in this matter.
Code volume: this one sort of speaks for itself. More code == more complex (is the assumption). It hasn’t been proven && it hasn’t been proven wrong….hmmm.
Gojko Adzic: How I learned to love flexible scope
This was one of the talks that sort of kicked everyone in the nuts. Basically, most of us are doing what we think is ‘agile’, but is actually ‘waterscrumfall’. There is usually still a deadline, a fixed scope and an expectation that software is ‘finished’ after period x, where ‘x’ is usually at least a few months. And this just doesn’t deals with reality. There are three unpredictable things: local, time and human.
Local: your solution might work at place X, but not at place Y because of cultural differences etc.
Time: Sometimes, another company releases what you are still building. You need to be flexible to work this one out.
Human: Humans tell you A, but then they do B. How dare they!!! That’s just how we are….
So, in order to fix our waterscrumfall we need to get out of our fail boats and embrace flexibility.
We have to SURVIVE and make a SELECTION.
Survive: Build software on a scale that you can still survive a fail.
Selection: use feedback to learn. “Who dares to delete code”, is a phrase that stuck with me. For some reason, throwing stuff away feels like a failure when it could also be a success.
I was thinking about ‘Thinking, Fast and Slow’ again here: the sunken cost fallacy. When you are on a road to failure, it might seem wise to just keep on going, when you could also call it quits and start over. That might save you time, frustration and money.
Roadmap: a real roadmap has options. What we usually understand as a ‘roadmap’ is just a map. We have to make user stories small in order to survive a fail, or: we have to keep our options open and not commit foolishly on something large and lose our flexibility.
Plan to learn! I think that was for me the key statement of this session. If we keep making the same mistakes in planning, thinking the world is as lineair as a planning, then really….what are we doing?!
And finally: user stories should clearly mention what value they add.
Scrum and Productivity – Anna Obukhova
This talk sounded really interesting on paper and I couldn’t wait to find out more. It ended up being a pretty scientific talk about ‘willpower energy’ and how that can affect productivity. The central question was “Why do we sometimes fail to adapt to a more productive life?”. We might be motivated, but our willpower can drain easily. The “willpower energy” is something precious and there are ways to preserve it better. The speaker claimed that the Scrum way of working is the most beneficial one if you want to preserve your willpower. This is because Scrum has only a few meetings and they are always at the same time. That gives us humans some stability, which is good. More meetings, especially unnecessary ones, are a willpower drain.
The talk also mentioned stuff about food and willpower. We need sugar to think and the more you think the more sugar you need. And what you eat also affects your “willpower energy”. She mentioned ‘lysine’, that an amino acid that occurs only in meat or other animal products (egg, milk). Therefore, the claim was that vegetarians have a hard time getting enough lysine and vegans are in trouble. This spawned some questions in me, since I’m a vegetarian myself. I’m really going to dig into this when I’m at home.
In order to boost your productivity you need to do three things:
Don’t spend lysine (work in flow, don’t do bullshit stuff)
Don’t allow other to spend lysine
Get results
The flow state is really important. In this state we are feeling creative and productive, we forget about time and we avoid boredom.
We should avoid stress as much as well, because this drains our “willpower energy” very fast. And that, in turn, affects the quality of our work.
All in all, I learned some new things in this talk, and it was refreshingly different than the other talks.
Dan North – The Journey to Mastery
This was the third time I saw Dan North speak and he really hit the spot this time. The journey to mastery is the “journey that never ends”. According to him, mastery is ‘being capable in a certain context’. There is even a formula for performance. P = p – i P = Performace (in context). p = performance. i = interruptions. So our overall Performance depends on a performance in a certain situation minus the interruptions.
Again, the keyword is FOCUS here. We need to focus in order to be good at something. You need to work hard.
Software craftsmanship is especially difficult. We are not alone, but in a team. A piano player who mastered his craft is just alone and has little distraction other than himself. It becomes more difficult for someone in a sports team. He needs to master working with others too. And a being a soldier is even more difficult. They need discipline, adaptability and instinct.
So when are you a master in software development?
There are three stages: apprentice -> journeyman -> master.
As a beginner you need to take your time to learn. Follow the masters on Twitter and learn from them. Study the basics and remember there is no one true way of doing things.
When you passed this stage it is time to build your portfolio. Try getting out of your comfort zone and learn things in a different domain. It is also very important to figure out how you learn. If you know this about yourself you can adapt your strategy. Furthermore: learn to listen to others. You might be wrong!
Finally, when you have become a master: help others and remember how it felt when you started. Never lose the joy in what you’re doing.
Decide on a GOAL, but also enjoy the learning process.
This talk by Dan North was so full of energy! My short summary doesn’t do it justice, but I hope the information is useful for you.
Testing the Hard Stuff – John Hughes
Darn, this guy was awesome! Some real magic going on in this hour.
The basic premise was that it’s impossible to ever test enough. Testing is hard and the effort just doesn’t go up lineair if you add more features.
The solution would be to generate your tests.
He then went on to demonstrate this with a tool called QuickCheck. In my notebook I see that I’ve summarised it as ‘complicated tool demo’. Yeah…that’s not really helping. He went really fast when demonstrating this tool, but I got the feeling that it was very useful on unit level. You could test component(s) very thoroughly. He demonstrated the tool, made the tests fail on purpose, would go ‘darn!’ and then edited his code to see if the tests would pass. All this was done in C, a language I don’t know. This guy put on a show that was very funny to watch. His presentation style is awesome, witty and …fast.
This talk was just a tad too complicated for me, but very inspiring to go and research this tool.
End of day 1