I test (mainly) & write (less so) software, studied physics. I like the ocean, mountain hiking & art. Languages (in alphabetical order): English, German, Ruby
As for the event: I hope to meet old and new friends, see a bit of Athens and bring hone lots of great ideas — and some greek (cretan, actually) thyme honey. :-)
The anniversaries we're celebrating at Euruko 2013 are a good reason to think about what you need to do, to create long lasting software. Let's think about the future of the software we're building.
Sure: If our software fails to provide enough value today (or at least in the near future), we'll probably be better off looking for the next job. However, software development is a game played in rounds — and most teams nearly always prefer to stay in the game for many rounds.
It's interesting — and a it worrying — that most of the testing techniques and approaches applied today are focussed on the current version of our software and its ability to solve to right problem and doing this correctly: We concentrate on a relatively short period of time.
However, we should also make sure our systems can cope with tomorrows requirements, customers and users. Therefore, let's look at some ways we can do this.
Thanks for the comment. You're right it is supposed to be a teaser as well as an abstract. I'll tell you a bit more about what I have in mind, yet, won't tell the whole story. Because, you know, what's the point of telling everything in an abstract (and/or teaser)? If you do, who's going to listen to you at the conf? ;-)
What I see a lot in many projects I've worked in, is that the better ones are using well described business scenarios for testing (whether these are automated or not, often written in Cucumber, if automated) and/or pretty detailed unit tests (automated almost always using RSpec, Mini::Test or what-have-you). And that's fine: If done right, these help team implementing the right systems and feature and it also helps to avoid bugs.
However, I learned that team should also have the future of the project in mind and be open to probable/likely new features and/or unanticipated uses of the system. I think we should find ways to explicitly work on topics as maintainability, expandability, etc. (It's called software for a reason.)
Hi, could you care to elaborate? Your abstract sounds more like an interesting tease :-)