Last weekend took place in Madrid Codemotion 2013, the second edition in Spain of this eclectic conference for software developers which was born in Italy seven years ago (the same brand has diseminated to other European cities, like Milan and Berlin).
When the event was announced, at Cycle–IT we saw that there were a bunch of good talks on tools and methodologies that we are following with interest — either because we use them every day, or because we are moving in that direction. So off we went Miguel Martín–Forero and yours truly. Here is a quick report on what we saw, mentioning some of the talks we attended. (We are leaving the most technical ones for subsequent articles.)
Code + emotion
The very fact that the conference is so broad in its scope is at the same time a virtue and a flaw — it is difficult to summarise the purpose of the event, if not by saying that it is a general conference for programmers in all technologies, and of all strands.
The line dividing designers and engineers is blurring… at least according to Facebook.
The general atmosphere is technical, relaxed and casual. Approximately 40% of the activities on the two–day agenda were in English, which gives us a hint of the ratio of foreign–to–Spanish speakers. Our impression was that among the attendees there was a vast majority of Spanish and Spanish–speaking folks, though.
The opening ceremony and keynote had a technical representative from PayPal as its main actor. It was a brief presentation, and its bottom line might be “PayPal loves developers”. We were given some impressive figures about the explosion of payments on the internet via mobile devices (specifically cell phones). To help programmers leverage all that potential within their apps, PayPal is putting new efforts into developer.paypal.com, trying to be more and more friendly to techies with mobile SDKs for Android and iOS and RESTful APIs. Another name to watch may be PayPal Beacon, a little USB dongle that will link automatically merchants’ POSs to customers’ mobile phones via a low–energy Bluetooth signal.
In this first post about Codemotion we want to focus on methodology, best practices in software engineering and productivity tips. In particular, these four talks delved into these topics:
- “Engineering design for Facebook”, by Jackson Gabbard.
- “Desarrollo de videojuegos dirigido por pruebas”, by Javier Gutiérrez
- “Agile anti–patterns: yes, your agile projects can and will fail, too!”, by Sander Hoogendoorn.
- “Siete técnicas para conseguir que un buen equipo llegue a ser brillante”, by David Bonilla.
Are we all devigners?
Gabbard, who is himself a hybrid programmer/designer, contended that the difference between designers and engineers is blurring. To support this notion, he shared statistics showing that quite a high percentage of so–called “product designers” actually commit to the codebase at Facebook. His own journey as a designer, back and forth into development, is testimony of this.
How to achieve balance between comprehensive unit–testing, little overhead, and prompt delivery of the product?
For Gabbard, the synergy between those two roles emanates from the fact that within a good team, “everyone cares”, and “everyone takes ownership”. And to achieve that, a sort of virtuous circle has to work — designers need to feed completeness (in their prototypes) to engineers, and the latter must pay all attention to details when they interact with designers. According to Gabbard, this “common ownership” is underlined by a popular quote from Mark Zuckerberg himself:
“Hacking is also an inherently hands–on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: ‘code wins arguments’.”
There remains the weakest point in this presentation, though: the speaker started by trying to convince us that there aren’t such separate roles as “designers” and “engineers” any more… only to spend the rest of the talk explaining how both can work and collaborate effectively.
“Testing” is the name of the game
From the talk by Javier Gutiérrez about test–driven development applied to (HTML5) games, we got, yet again, the need to integrate tests from the beginning within our whole development process. Because at Cycle–IT we are focused on UX, interfaces and visual aspects, we were expecting juicy details about proper unit–testing of interfaces, graphical elements, user interaction, etc. Instead, it appeared as if testing the (HTML5) interface means just testing the underlying objects and data structures.
We suspect that complex HTML5 interfaces are starting to face, when it comes to testing user interaction and visual feedback, the same issues that we have seen for years now in Flex applications. There is a niche for good tools capable of intercepting and simulating that interaction on HTML pages.
What is clear, in HTML as in Flash or in any other technology, is that the right balance between productive unit–testing (one that works, but does not involve a huge overhead) and quick development and prototyping is hard to achieve.
Doing things right
Sander Hoogendoorn is a senior consultant in agile projects, but no zealot. If there’s something to learn from his slides (and his harsh sense of humour) is that sensible criticism of any methodology, paradigm and technology in the industry is always healthy.
In a sentence: while it is true that “waterfall should have never existed” (sic), agile is not the silver bullet, either.
In forty–five minutes, Hoogendoorn bashed everything, for the great delight of the audience — the waterfall model, trendy XP ideas, SAP, so‐called “scrum masters”, Java, gemba walks… The reason we cannot blindly apply agile approaches (or any other approach, for that matter) to our software projects is that teams and projects vary wildly. Approximately 70% of processes within a team are similar to those we can find in other teams. But the remaining 30% implies a lot of differences in the way those team may need to work and communicate.
Similarly, recent attempts to institutionalise agile approaches are in themselves an indication that there’s something wrong. There are aspects of software craftmanship that agile people often overlook, but are really important. One example would be detailed documentation, which in many cases is paramount to ensure long–term maintenance of the product, and in spite of always preferring “working software”.
Snake oil vs. sensible advice
To wrap up this first summary of interesting talks at last Codemotion Madrid, a quick mention to David Bonilla and his recipe to turn a good team into a brilliant team. The slides are available online (in Spanish). In a nutshell, those seven techniques would be:
- Keep the flow. Avoid distractions during your periods of maximum productivity, eg implement the pomodoro technique.
- Feed your brain. Stay motivated and awake, learn new things, organise seminars or brown bags.
- Give kudos. Say “thank you!” and “well done!” more often.
- Use a report robot. Information radiators, automated statistics and metrics, etc.
- Eat your own dog food. Use your own software! Alpha–testing.
- Celebrate special days. Organise events and parties off office hours.
- Experiment. Research, try and play with stuff to stay motivated and come up with out–of–the–box ideas.
(Companies are giving away weirder and weirder goodies at conferences in these days!)
