We, the developers, are crazy. Surprisingly, that’s what we have been told at the very beginning of the DevDay conference. The speaker (some ABB guy; I arrived 5m late and didn’t catch his name) with a strong Slavic accent made his point about passion, self-motivation and personal abilities in the world of software development. At the same time, he would compare it to his hobby – running. We are crazy, because we get up early on Saturday and get together to devote the whole day to nerdy IT topics. The guy is crazy to run marathons. I guess that’s what passion is.
Good appetizer for the upcoming sessions.
Throughout his talk, Jon would give dozens of examples of discrepancies or inconsistencies concerning the three basic data structures in computer programming: floating point numbers, strings and dates.
In his truly amusing performance Jon collaborated with Tony and the audience, asking apparently obvious, but in fact hideously tricky, questions, backed by a snippet of code. Tony, for instance, failed to remember that:
in java has in fact the exact value of:
Then Jon focused on UTF-32 strings in Java and C#, and various ambiguities related to: the zero-width character, reversing character arrays containing UTF-32 character modifiers (i.e. accents) or \r\n line delimiters. He also mentioned the ultimate test for your software: the infamous Turkey Test.
The third, yet most outstanding part of the presentation was focused on handling dates (Jon is the author of Noda, a .net equivalent of Joda-Time – a date & time ops library). The amount of corner-cases stemming from progress in science, historical events, political decisions all over the globe and even random mistakes is ridiculously hard to imagine:
- leap days;
- leap seconds;
- time zones;
- daylight saving;
- Julian and Gregorian calendars (and countries switching from one to the other at different times and pace);
- Samoa which has recently changed its time-zone in order to be the one of the first countries in the world to celebrate New Year’s day;
- Sweden, which is the only country in the world where February had 30 days by mistake, once in 1712.
- Brasil and its extra-ordinary night without midnight;
- local time discontinuities;
- ambiguous time-zone names, e.g. “CST” might mean 3 different things!
Amazing opening keynote. Next time I’m going to think twice before I code any date-related logic!
Another good talk. This time, a handful of hints about how to go agile in a company of 1000+ employees, based on real-life example: Spotify. I loved the simplicity and purity of the slides, that Dariusz used as a background for his story. Also, all the references to jazz music here and there, made the presentation feel very authentic. Music is what Spotify is all about, after all.
The elementary organizational unit in the company is a squad. It’s a fully autonomous, cross-functional team of 5-10, including a Product Owner, Team Leader, and Agile Coach. A squad is responsible for delivering a certain feature as a whole (coding, UI, process, integration, deployment, etc.). Spotify strongly believes in people’s motivation and creativity. Long story short – the way to achieve them is to give people the autonomy in making decisions, let themmaster their craft, and lead them towards the big-picture purpose.
Spotify’s recipe for success is the idea behind the Lean Startup movement – everything is just a mere hypothesis, that one has to validate against the reality with a bit of experimentation. Then measure the effects and learn from it, to be able to push the product in the direction, in which the customers want it to go. Dariusz says the squads feel like mini-startups, so that the whole model pretty much encourages experimentation. However, it doesn’t scale out this easily – there are squads which are responsible for driving the whole product, for UI design guidelines, managing other squads, etc. I wonder – is it really so fundamentally different than the usual hierarchical company structure?
Funny thing, when the slide “All the music in the world, for free” (Spotify’s motto) had popped up, Dariusz explained: “well, it’s obviously not all the music in the world”. The audience instantly replied: “and it’s not for free” :).
Quite a technical, yet interesting talk given by @TheCodeJunkie, focusing on C# language mechanisms one can use to help make a framework or a library feel more developer-friendly (based on code excerpts from Nancy, a web-app framework, a clone of Sinatra). Among other, he mentioned dynamic types, implicit constructors, leveraging the power of marker interfaces, and automatic assemblies’ scanning. All nicely presented, with focus on the code.
Frankly speaking, I hoped that Andreas would give some general advice on developing a framework. Writing an easily reusable library in any language is always a challenge, usually because it’s hard to predict how people might want to use the code/API. Being a Java developer, I felt a bit disappointed that his talk boiled down to C# details or hints. Not any rocket science at all, but anyway I’m pretty sure, that .net guys might have found it quite helpful, or at least that it might have served as a reminder.
Ben Hall, an experienced entrepreneur with IT background, told us an exciting and incredibly inspiring story of his ventures. To tell the truth, there was barely anything that would go beyond the lessons Eric Ries had given away in “Lean Startup”. Nevertheless, sharing the real-life experience of his projects, talking about all the wrong turns that he had done in past ventures, is the best Ben could ever give away to us. Priceless knowledge – when you can learn from someone else’s mistakes, isn’t it?
I’ve jotted down a handful of quotes or ideas, that I find particularly worth spreading. Here they are:
- Don’t fail because of preliminary doubt “no-one is going to use it”.
- It’s easier to go from shit to great, than from nothing to great.
- People are rubbish at predicting the future, so stick with their past experience. “I’m definitely going to take on buying shoes on the Internet” means there’s 0% chance that I could ever do that.
- Don’t waste your time writing boring code. Do stuff that really moves the needle!
- Who cares about clean code if there are no sales?
- Keep it simple, keep it dirty, whatever is required to get the job done. 4sq API, screen-scraping, hidden APIs.
So simple, so true and so obvious, yet sometimes easier said than done.
Ben once said he had spent 3 hours on developing a certain Minimum Viable Product (a Rails app with some dummy Redis store), then 1 hour to come up with a web page for his product (with some online drag-n-drop creators). I was completely struck by how little time he had needed to get things done, build the MVP (actually mocking some core features), and start measuring the results to validate his business hypothesis. Now, that’s damn agile, don’t you think?
Ben Hall says MVPs are all about quick and dirty solutions. Can’t agree more. That’s definitely not something you would cope with easily, when TDD, BDD, SOLID, clean code and high quality are rooted deep into your mindset. To be really agile and effective in this case, you need to put all the rules aside and quit looking behind. Reuse open-source building blocks, glue them together, patch them up, mock whatever you can, do whatever the hell it takes to get the job done, but not more.
Towards the end of the talk, I felt as if I had superpowers. Thanks Ben!
The ability to explain complex things in a simple way is definitely a valuable asset. Itamar proved that he’s got that talent, as he described the internals of Lucene – an advanced, mature, Java-based, full-text search engine. He went through the idea of constructing inverted indices out of input data, as a key for great performance in search. He gave a broad overview of what Lucene is capable of, with it’s features like normalization, stemming, stop-word support, weighted keywords, faceted search, geo-spatial coordinate support, and a lot more. Itamar went a step further and named a few examples of where (and how) Lucene can be used in other applications:
- product suggestions like “People who bought X, also liked Y & Z”;
- autocomplete suggestions feature in search widgets;
- faceted searches (grouping search hits by a category) – e.g. Amazon;
As predicted, Itamar recommended the famous Elasticsearch project for scaling Lucene, its convenient RESTful API and tons of plugins. Well, that’s what I would do too :).
In general, Itamar didn’t dive very deep into the details, still he sounded very knowledgeable, convincing (never overconfident) and precise about what he was saying. Although’ I’ve been using Elasticsearch for quite some time now, his talk helped me rethink and reorganize my knowledge of the topic in general.
To tell the truth, I couldn’t believe in what Marco was saying: the whole StackOverflow infrastructure boils down to less than 25 servers and they are all located in NY (well, there’s also this backup site in Oregon):
- 11x IIS web servers,
- 2x SQL servers,
- 5x elasticsearch servers,
- 2x redis servers,
- 3x servers for tag engine,
- 2x load-balancers.
In fact, the foundation of StackOverflow architecture is caching. Several layers make it impressively effective:
- memory cache,
- database cache,
- at last resort: read from database files on SSD disks.
“Scale up first, then out” they say, and that’s what the stats show. Marco claims, they could probably fit into ~5 servers and still be sound and safe. I expected diagrams with tons of layers, tiers, virtual machines in the cloud. What I got, was pretty much the opposite. No need for over-engineering, KISS.
Another surprise was that the entire StackOverflow solution (9 projects, ~100 KLoC overall) has exactly 287 tests in total. In this case, it’s the hyper-active community, which replaces the need to write tests for the software. I would never imagine such process may actually take place in systems of that popularity and traffic.
“Move fast and break things*”
* not the homepage :)
To sum up, it was one of the surprise-surprise kind of presentations. I particularly liked the enthusiastic, open-source attitude and the information transparency – Marco logged into their admin console and gave a short tour of the monitoring widgets on the live system. Btw, some nice monitoring tools, they have. Marco promised to share it with the community soon :).
Side-note: “The Jon Skeet problem” – when Jon happens to be the first person to trigger some SQL query, it’s execution plan is carefully tailored and compiled for Jon’s account – not really an average account :). Clearly, it proves terribly inefficient, so they have to recreate the plan :).
Someone tweeted: “Some long-haired guy is showing his holiday pics”.
Outstandingly strong voice, loads of funny stories and fast pace resulted in an invigorating and inspiring end keynote of the conference. Inasmuch I’ve taken ~8 mini pages of notes through the whole day, I didn’t write a word on Rob’s presentation. It all happened blazingly fast with a volcano of energy :).
It’s been my first ABB DevDay, and I admit it’s been the best free conference that I have ever attended.
After my second thoughts, I came to the conclusion that the event (or at least the path that I chose) was ideally balanced:
- A general topic, a brain warm-up: Tony the pony & Data Structures,
- Agile techniques at Spotify,
- Technical speech on Nancy & C#,
- Startups, entrepreneurship, MVPs,
- Semi-technical again, Lucene explained,
- Architecture of StackOverflow,
- Mind blown and a fascinating career episode story.
A bit of everything, but nothing missing (well ok, maybe Scala.. :)).
In my opinion, the greatest quality of the event is a noticeable focus on people, not on companies. No flashy marketing stands, no intrusive recruiters, no useless contests. Just the people, genuine atmosphere and the great feeling of being part of a united community.
Not to mention Mexican waves hitting the auditorium, group photos with the speakers and the debugging crew on the stage, free beers and lots of fun.
Thank you, ABB. Motivated I am!