Thursday, June 19, 2014

QCon New York Day 3: Humans and engineers, Career Development, Remote Teams and Culture

Building a NoSQL database

Man, my brain still hurts from the first two days, especially around all the clarities of micro-services. But, longing for more information, day 3 started with another keynote. Not as good as yesterday's, but the story about how Amazon build their own NoSql database contained some nice lessons. For starters, they insisted on planning for both scalability as well as failure. The former is usually something that doesn't get immediate attention, but that's usually still more than what we do with the latter. And again, Netflix is being mentioned since they invented Chaos Monkey and Latency Monkey. Another thing that I do agree with is consistent performance. How many companies actually monitor performance day by day? In my experience dev teams only start addressing performance when there's an immediate issue. One interesting concept they introduced is the Blast Radius. During their failure testing they explicitly analyze how far that failure reaches into the application landscape. With that information, they've tried to tune the interfaces between components to become a bit more resilient.

WP_20140614_11_21_36_Pro

Mentoring engineers

To my surprise there was an actual TypeScript session in this slot, but the title of another session -- Mentoring Humans and Engineers -- sounded too interesting. Daniel Doubrovkine showed us how he approaches mentoring new employees within his current organization. They've based their approach on his experience that getting the strongest people at any level and keeping them is the single hardest thing in any organization.

This all starts by promising an interesting learning experience, both on the job as well as outside the job. For instance, new employees are also shown around in New York. What places they should visit. Where to find a nice place to stay. How to meet-up with new people. Next to that, they pick their mentors from the most experienced, pragmatic AND patient people that understand starting with clear milestones and then gradually moving to goals is the best. They know that fostering ownership and trust is essential, the room for self-exploration is required, while not overwhelming them with both information and too much freedom.

Even more important (and something I often forget in my desire to help teams) is that failing is okay, as long as you learn from it. You should really create an environment that provides feedback, but take responsibility to protect them from anything that would de-motivate them to try new things in the future. At the same time, teach them how to fail by given them an assignment that is difficult or impossible to do. And don't forget to advertise them within your organization. Always introduce them to whoever you run into and openly praise them for any accomplishments. Daniel's closing statement was particularly interesting since he warned us not to underestimate a young new colleague. They might be much smarter than you are….

Climbing off the ladder, before we fall off

Spotify has been a big example for us, especially through Henrik Kniberg's excellent book Lean from the Trunches. And QCon wouldn't be QCon if they would not have a Spotify session. Chris Angove, a chapter lead from Spotify New York explained how he tried to find the balance between alignment and autonomy (or "do what I say" vs "do whatever"). They quickly discovered that this is destined to fail, simply because these two ends should be orthogonal. Instead of that, they tell their engineers what to do, but don't tell them how to do that. Somehow this freedom brings along a lot of responsibilities. To help the teams know their part in the big picture, they can give them missions, short-term goals and a product strategy.

This is all fine and well, but after more than two days of sessions, this is not what sets them apart from the rest. But what did is the way they approach career development. Traditional companies generally use a linear ladder where a software engineer can potentially climb to senior software, architect or even CTO. This provides a clear structure for promotion, and thus more salary and status. However, according to Chris this model can also be a factory to eject people due to limited management positions or by promoting people beyond their capabilities. In short, it provides simplicity for the manager, not the engineer.

Alternatives exists. For instance, some companies use two ladders; one for management positions and one for software engineering positions. Although it provides a technological track, and it clearly sets up easy ways to recognize accomplishments, it still looks like a linear ladder. Similarly to the previous model it assumes that the only way to grow is to take more responsibility or control. It still doesn't answer how to experiment or switch between roles.

Spotify believes that people that add value should be paid more money regardless of their role or position. To support that they stimulate engineers to try something new, which doesn't necessarily mean they stop what they are doing. In other words, they try to get them out of their comfort zone, to acquire a new skill and to push themselves in a new direction. More specifically, to shake things up a bit and see what talents or skills somebody really has. So instead of this rather rigid ladder, they've introduced add-ons that add both personal value as well as business value aligned with the skill-set and interests chosen by the engineer. In a sense it is engineer-driven but supported by company. The manager must work with the engineer to help him or her to find those challenges or even define a completely new add-on, or even giving them some time off to attend trainings, sessions or workshops. And those add-ons don't have to exist upfront. It is perfectly fine for an engineer to come up with another add-on that adds value to the company. Some the add-ons currently being tried at Spotify include a speaker, a road manager, coach, evangelist, mentor, trainer, writer or even open sourcer. Even an architect is treated as an add-on, simply because they help in alignment rather than to make decisions. If you ask me, this sounds like a great model.

Interviewing for culture

Another slot in this awesome conference with an open-space session on culture. This included a great discussion on mentoring and how important this is for your career. Several of the participants shared their opinions on how a junior engineer needs to be taught on how to get the most out of this skills and how to advertize him- or herself within an organization.

Another discussion was about how to determine if somebody is going to match your organization's culture during an interview. Inviting somebody for lunch helps to see how somebody behaves in a new group was one suggestion. Having full-day interviews to allow the person to relax was another. However, one participant said they stopped doing that because candidates would be completely drained at the end of the day. Another participant told us that upon arrival of the candidate, they first asked about there private life, kids, etc and then came back after 5 minutes or resulting in a much more relaxed interview. Doing code assignments from home is also very popular, but some mentioned they were worried the candidate would game that system.

The final topic dealt with introvert colleagues. I explained how something like Flowdock seems to help those people that have great ideas, but just don't feel comfortable enough to share that in an open discussion.

WP_20140614_15_43_48_Pro

Remotely working at Github

Last year's talk by Github employee Zach Holman already showed many of the merits of that company, and this year Matthew McCullough continued by elaborating on some of the things they do to foster remote working. I already knew that Github employees can spend 20% of their time on innovations, learning new things, but I didn't know that on average 70% of the people work remotely. That explains the amount of energy they put on building tools and offices that support that.

For instance, they've build an internal app that provides a central location for discussions, sharing ideas, their internal communications handbooks and having live video chats. They also organize mini-summits where two engineers can do an internal talk which is then shared through that same app. Even cooler, they build tools to allow them to listen to the same music all over the world. So if somebody makes a remark about a cool song at the other side of the world, it's almost as if they work at the same office.

They also pro-actively build small offices with a living room or café-styled look as well at different places in the world to allow people to have a nice place to meet informally. Those offices also have some kind of phone booths to work in In fact, to better understand how it is to live outside of the US and in a different time zone and to work on a global project, the CEO decided to move to Paris for a year or so. They also organize beer:30 meetings where teams have informal virtual meetings with other global teams.

While discussing the communications guide, Matthew shared some of the foundational principles Github. First of all, teams make decisions about what they do, not committees of carefully selected people. Egos are not allowed in discussions. In the end, the best argument wins. That's an interesting statement, especially considering my own challenges to give somebody enough room to make their point sometimes. But even more striking is that everything is open within Github. The financial situations, salaries, expenses and even meetings that deal with the future and strategy of the company.

That's definitely something I have never seen before and from which a lot of organizations can learn from…

Friday, June 13, 2014

QCon New York Day 2: Freeing people, imperfect architecture, lean coffee and unanswered questions

That was the weirdest conference party ever. No music, no dancing, just free food and beer. Well, our of me, two Austrian guys and a fellow from Dakota had plenty of great stories to share. And did I mention the free beer?

clip_image001

Freeing people and optimizing the tools

As any good professional would do, I also was at the conference venue on time, just like anybody else. And for once, the keynote was worth my time. Dianne Marsh, director of engineering at Netflix shared how Netflix ensures their engineers get the freedom to innovate. Their basic vision is to let free of the people and to optimize the tools. They do that by having their managers provide context rather than control the people and try to attract and retain talent. Obviously engineers have the tendency to go any which way they can, so managers are supposed to help them to have some kind of alignment.

They also should stimulate experimentation in independent paths of exploration. If you've been attending the Lean Enterprise talk from Trevor Owens you should understand why that's such a great thing to do. Next to that they heavily invests in continuous delivery. Developers can test and deploy their own code using a fully automated deployment pipeline. If this involves larger and more risky changes, they do what they call a red/black deployment or canary testing. In other words, they run the two versions side-by-side and gradually move our users from the old to new environment.

One other thing that caught my attention is how they approach software development as something that can fail at any time. That’s why they created the Chaos Monkey that will shut down random Amazon VMs to see how the system behaves and the Latency Monkey that will cause timeouts in network connections at random times. This is pretty special considering how often that day I heard references to that in architectural discussions.

In all seriousness

Michael Feathers is one of my hero speakers, not only because of his excellent book, but also because most of his talks are really inspiring. He has spoken about Conway's Law numerous times, but this was the first one where he used this law to propose organizational solutions. Roughly he said that irrespective of the greatness of your architecture and all the agile practices your applying, sooner or later you'll run into scaling issues caused by the organizational structure. I've been working at a client that grew from 8 to 120 people in about three years and Conway's Law is really visible there. It starts to get particular difficult when you can't get all the developers on the same floor. That's one of the reasons Michael has a great interest in the whole micro-services hype. Since each micro-services can be maintained by at most one team, it provides not only architectural scalability but also on the organizational level.

Embrace Imperfection

Right after Michael, I went to Eric Evans' talk on embracing imperfection. Last year I left his full-day tutorial on Domain-Driven Design because it was too boring, but this session was absolutely great. After admitting he wasn't really sure what architecture really is (!), he talked on our failed attempts to build robust and resilient systems. That's why he believes Netflix is doing such a great job. They've essentially managed to reach perfection in handling imperfection. As a long-term architect that will profoundly affect my future endeavors.

Provided that I understood him correctly, his general rule-of-thumb is that within a bounded context (BC) you should have 90% of the functionality covered by an elegant architecture. The remainder doesn't have to be so perfect, as long as the BC is aligned with the team structure. That ensures that any shortcuts that are taking are well-known within the team and won't surprise other teams. By further decoupling the BCs from each other using special interchange contexts that translate messages between BCs (aka the Anti-corruption Layer), and not sharing any resources such as databases, you can localize the imperfections. Oh, and with that statement of 'not being so perfect', he actually meant to use if-then-else constructs rather than well-designed polymorphostic abstractions!

clip_image002

More Eric and Michael

As if this day wasn't already great enough with individual sessions, wouldn't it be cool to have the both of them open up a panel discussion on architecture? Well, here you go. In fact, that panel was joined by Leo Gorodinski who used Greg Young's EventStore to build a system in F# and Duncan DeVore who build an Event Sourcing system in Java. Yes, you've heard that right. They were actually discussing Event Sourcing as an architecture principle in the context of micros-services at Qcon. After the session I talked a bit more about that with Leo and Duncan and they told me that Event Sourcing is only recently getting recognition outside the .NET world. Guess I should be proposing a talk on distributed occasionally connected systems using Event Sourcing for next year then. Anyway, one question that was discussed quite extensive is whether domain modeling, or more specific, aggregate boundaries are still useful while developing micro-services. I couldn't judge the later, but in the context of event sourcing I shared my experience that having proper aggregates allowed us to move from a traditional relation database system to Event Sourcing without too much of a hassle. However, I also shared that Event Sourcing is not a silver bullet and you should be prepared to the need to learn a lot of new technical and functional concepts.

Lean Coffee

To stay within the context of the architecture panel discussion, I attended a Lean Coffee session on improving architecture. Lean Coffee is a simplified version of Open Space where people can propose topics that are openly discussed for a maximum of 5 minutes in the order defined by dot voting. I even asked Eric, Leo and Duncan to stick around for this talk because there were a lot of questions after their session.

clip_image003

Since 5 minutes is short, we covered several topics:

How to handle exceptions in an event-based architecture; After a short discussion we learned the attendee meant a command-based architecture. Somebody proposed to have a callback REST API that command handlers can report errors to. Others proposed to associate each command/event with a correlation ID and have some framework in place for registering errors. I myself proposed to validate the command for correctness synchronously and handle any business errors asynchronously through a centralized registry, but keeping the errors really functional.

How to compose micro-services from aggregates and how to select the right size and maintaining micro-services; Talking about awkward silence, this was one. Nobody in the group had the experience nor got anything from the QCon sessions that could answer this. Bummer…

What else are people talking about EXCEPT micro-services; Since I'm working with an Event Sourcing architecture and this was also discussed in the previous panel discussion I shared some of our trials and tribulations of moving from a traditional architecture to ES.

Usual stuff you do to improve architecture and how to visualize and/or measure this; Most of us mentioned the SOLID principles, reducing technical debt, pair programming and code reviews, but we couldn't entirely agree on DRY. Some of us thought DRY within a component or bounded context is important but outside that boundary is not too important. This especially aligns well with Conway's Law because preventing duplication between teams is a lot more difficult or even undesirable. However, not everybody agreed with that.

Six questions on micro-services I hoped to get answered, but didn't

So after two days of architecture sessions and discussions, I still have a lot of questions unanswered…

  • How to group aggregates in micro-services?
  • How do you prevent a micro-services from growing too quickly and becoming macro?
  • Should micro-services call eachother or should they publish events only?
  • How do you version messages to be both backwards compatible as well as forwards compatible?
  • How do you manage the dependencies between the services?
  • How do you effectively aggregate data from multiple services to prevent N+1 calls?

Anybody??

Thursday, June 12, 2014

QCon New York Day 1: Micro-services, Team Latency and the Lean Enterprise

So now that I've got the unofficial part of this trip behind me and I managed to get through a very in-depth full day workshop on reactive extensions in JavaScript with my limited JavaScript experience, it is time for the main part of the conference. As is customary at QCon, each day always starts with a pretty boring introduction of all tracks by the track owners. I'm honestly wondering why they force those people to get on stage for such a large group. They are obviously very uncomfortable with it. Even the guy that opens up the day sounds like he doesn't actually want to talk about QCon.

clip_image001

Dart

Anyway, Gilad Bracha, Google employee and author of Newspeak brought us up-to-speed on web programming in the future. He promised not to make it too much of a marketing talk. But after several (not so succesful) demos on Dart he horribly failed on that promise. Why not invite Anders Hejlsberg and let him talk about TypeScript instead. That is a speaker with excellent speaking skills, has charisma and can tell a story.

Flight

In my current project we have historically used KnockoutJs, but we are in process of switching to AngularJS for the newer features. Twitter has been sharing their internal framework called Flight, whereas Facebook is actively pushing React, a JavaScript framework based on the concept of a virtual-DOM. To get a better understanding of the first, I decided to go to Kassandra Perch's (unexpectingly short) introduction. Well, either I didn't pay enough attention, or my JavaScript experience really is hampering me, but I totally didn't get what she was doing. I might be wrong, but those JS classes looked like she was coupling the DOM and the UI behavior within the same code. Call me a purist, but avoiding this is what EmberJS, AngularJS and KnockoutJs have been doing all along.

Oh, and one of the guys in the audience asked her how to select the appropriate framework for your project. She proposed to create a nice table and do a feature comparison of the various frameworks in the context of your project. I think that is stupid. You're not going to understand a framework's limitations if you don't actually use it in a real-life scenario. Just do a spike and see if you can rebuild an existing page using the framework of your choice.

Accidental architecture

Historically, the Open Space concept has been one of the best aspects of a QCon conference, so I decided to attend one about architectures you always wanted to learn about. Its painful to see how many people are facing the same problems over and over again, and how few opportunities you have to share experiences. Somebody was proposing the topic of accidental architecture but every a short discussion she actually concluded that they didn't have a known architecture at all and hardly any process. Each developer took a story, wandered off and did their own thing. In my own experience, authority and rules are not going to work, so I proposed to using an open space within the organization to find out what problems the developers themselves were facing. If they see the problems themselves, they are more likely to try to fix it themselves as well.

clip_image002

Micro-services

I also talked with somebody who has like a 100 micro-services running in production and is suffering from operational issues and data consistency problems. They were trying to solve the event up conversion the same way as we do in our Event Sourcing architecture and threw in all kinds of enterprisy products to help them. As far as I can judge, they were far ahead of what I've heard at QCon. We had a nice discussion and we both concluded that their next challenge is to accept that it will be impossible to keep all the micro-services in sync in terms of message and API versioning and that they should invest heavily in pro-active signaling and continuous delivery of those services.

More micro-services

Talking about micro-services, I also attended a talk by Yoni Goldberg on how Gilt, a US fashion outlet site, decided to break their monolithic website into about 50 micro-services each owned by a separate team. They used Docker to ease deployment of those services on shared Amazon VMs. According to the speaker they were very successful in that migration, but were now facing the more operational challenges of supporting so many dependent services. Apparently he has taken the same conclusion that tooling for supporting that, as well as continuous deployment, are becoming more important by the year. He concluded the talk with the advice that if you consider moving to micro-services, just start building every new feature as a micro-service and add the required tooling along the way.

Anyway, I'm not yet convinced about this micro-services thing. It solves certain problems quite nicely and is very scalable, but it also introduces a lot of new challenges around API/message versioning, finding the right bounded context and operational support such as monitoring and pro-active signaling. For now, nobody has really solved this entirely.

Team latency

Edmund Jorgensen delivered a refreshingly fun session on the latency of teams and how bringing down latency is best thing an organization can do. So many managers are focusing on the short-term needs rather than understanding how expensive any form of latency is. Think of technical debt, manual deployment steps, or anything else that prevents a team for speeding up. His basic approach is that reducing latency creates information earlier and early information is worth a lot of money. In fact, it saves money, so why do manager still persist on spending all their capacity on building features rather than having a good balance between functionality and reducing latency. Somehow, during his talk I had this sense of a déjà vu, like I've had heard the exact same story before. And then I realized that he was actually the author of this excellent article on speeding up your engineering organizations. Go make sure you read that.

The Lean Enterprise

The final session of the day was delivered by Trevor Owens, the author of Lean Enterprise. He showed us that a lot of the current successful startups were founded by prior Google developers. So why did they leave and became so successful? Well, according to his findings, using equity instead of salary as an incentive really gets people to innovate while most organizations have a rather traditional reward system. He also used a lot of fun facts from the world of the venture capitalists and how they never bet on a single horse. In fact, their entire investment strategy is based on the approach that one of the investments is going to be paying the losses made by the others. So he advices organizations to have multiple teams work on innovation at the same time. Or even better, let them leave the company, do their innovations autonomously and then buy them back, just like Google did. I'm definitely going to read that book.

I also attended the evening keynote prior to the conference party where Peter Wang tried to get us to focus on the bigger problems like early innovators did rather than on what technology stack to use. He's a great speaker, but by then my brain was already starting to shut down. Attending in-depth QCon sessions from 9 until 19 is not for the faint of heart.

Wednesday, June 11, 2014

The Staring Game aka The Art of Social Intelligence

So here I am in New York, all alone and looking for something fun to do during a rainy day preceding QCon New York. The Empire State Building was covered in clouds so what can you do? Well, you go to meetup.com and browse the many events that happen in a big city like this. Country dancing and role playing games didn’t really appeal to me, and I could have gone for a movie or just go to sleep early, but learning about social intelligence did sound rather intriguing.

WP_20140609_11_01_41_Pro

I decided to make the plunge and took the metro to one of the WeWork offices in NY. Upon arriving I first met Eric Waisman, the host of the evening and co-owner of Jaunty, a San Francisco-based company that helps people to improve their soft skills. They've just opened shop in NY and wanted to take the opportunity to use this free workshop to increase awareness about them. It's because I don't live in the US, otherwise this would have most definitely not been the last time I attended their workshops.

After the little office quickly filled up with a group of about 16 man and women from different professions, Eric elaborated on the social aspects of our life and how we have a lot of primitive believes and embedded behavior that are still there from the time we lived in caves and had to fear for our lives. Approaching somebody, regardless of whether that is a beautiful person, a potential business partner, or asking your boss for a raise always feels like a scary thing to do. Eric tried to scientifically explain why we behave like this and how stupid it is we're letting ourselves held back by that. He used a model of skills and believes to illustrate that. After last year's Culture Engine, I once again had this 'that makes a lot of sense!' erlebness.

He also talked about the pyramid of attraction, and how internal and external status, health, emotional stability and your ability to logic affects the way people perceive you, both professionally and personally. I particularly liked the distinction he made between internal and external status. The former is more about confidence, skill set and the believe system you have, whereas the latter deals with the more obvious things like money, beauty, the job you have and the part of city you live in. But these are just the most primitive parts of the pyramid. Emotional stability and logic are build on top of that. And as he explains, this also aligns nicely with the development our brain went through over the hundreds of thousands of years the human being exists.

The skill set part of that discussion got some attention as well. Amongst them he covered social skills, body language, conversational agility (I love that word!), assertiveness, humor, magnetism/charisma and approach. Eric strongly believes that all those skills can be learned and a lot of the workshops and trainings Jaunty gives are targeted to improve those skills. What I particularly liked is that he went to great lengths to define those skills. We all have an idea what those skills mean, but if you would be asked to define them, I'm quite sure a lot of us can't (including myself).

Of course, it wasn't just Eric doing all the hard job that evening. Oh no, not at all. To overcome our own fears, he wanted us to go outside our comfort zone and rather than looking at our mobile phone for a chance, stare somebody in the eyes for 5 minutes!! I have had my share of uncomfortable moments, but staring another dude in his eyes at a distance of half a meter for so long has been…let's say…a unique moment. Oh, and did I mention that you were not allowed to laugh or smile? But somehow it worked. Later that night I managed to freak out a lot of people in the metro. Looking forward to try this on my colleagues next week…

The other exercise we did was to read a person without prejudice and keep a conversation going. At the beginning of the workshop he promised us to that after that evening we would never end up in in those awkward silent moments in a conversation anymore. It was a bit over the top, but worked remarkably well.

I didn’t want to spoil the entire workshop, so if you live in New York or San Francisco, I would strongly advice you to keep in touch with Eric. He is a brilliant coach and really knows what he's taking about. Of course this is all just a model, but I already feel I learned so much from those first 4 hours. Thanks Eric.

Tuesday, May 20, 2014

Time to break with the past a.k.a. Fluent Assertions 3.0

Boy do I love the .NET community. Since I moved Fluent Assertions to Github, people have been creating 32 forks and provided me with 37 pull requests. In fact, release 3.0 has been made possible by the likes of Adam Voss (who provided a lot of those pull requests), Maarten Balliauw (for setting up a Team City environment) and Oren Novotny (for building and publishing the Xamarin version). However, that's not all. Other contributions were provided by Kevin Kuszyk, Kai Eichinger, Gregor Stamac, Sam Holder, Philipp Dolder and Mark Lambert. I can honestly say that this release would not have been possible without those people. Anyway, just in case the release notes are a bit to concise, let me highlight some of the bigger changes in 3.0.

Powered by

clip_image001[4] clip_image002[4]
clip_image003[4] clip_image004[4]

The biggest problem in terms of maintenance has been the work to support the different framework and device variants of the .NET Framework. Up until recently we had to use file links to get the same set of source files compiled into different projects. Because that has been so cumbersome, at some point I started to become reluctant in refactoring classes into new ones, just because that would mean fixing up those file links. Some of my Twitter followers tried to talk me into using Portable Class Libraries, but saying that that conversion was a challenge is an understatement, in particular the mechanisms to hook the framework-specific parts into the PCL.

Anyway, as of version 3.0, FluentAssertions consists out of a single PCL assembly post fixed with .Core and one platform-specific assembly. The only drawback of this is that you need to retarget your unit test project to .NET 4.0.3 (which is Update 3 that was released in March 2012). However, if you're working with Visual Studio 2013, you already have the 4.5 runtime installed and you just need to get the Targeting Pack for .NET 4.0.3 which Visual Studio will download automatically for you. For that same reason, we also dropped support for .NET 3.5. If you are so unfortunate to still have to develop in that version of the .NET framework, stick with 2.2. It's in maintenance mode, which means we'll still fix bugs if necessary.

Since we use Semantic Versioning, the bump to 3.0 clearly means it contains breaking changes. So we took that opportunity to remove some of the stuff that was marked as obsolete. Amongst them is the old API for asserting the structural equality of two object graphs ShouldHave().AllProperties().Equal() which was superseded by the ShouldBeEquivalentTo syntax and the ComparisonMode enumeration that was used during exception message assertions.

Reading back on the post, you must be thinking that 3.0 is just a step back. But it also contains some nice improvements as well as a few important bug fixes. One neat feature is the ability to chain a specific assertion on top of an assertion that acts on a collection or graph of objects. It's something we've been looking for for a long time, but it was Sam Holder that proposed this syntax.

dictionary.Should().ContainValue(myClass).Which.SomeProperty.Should().BeGreaterThan(0);

someObject.Should().BeOfType<Exception>().Which.Message.Should().Be("Other Message");

xDocument.Should().HaveElement("child").Which.Should().BeOfType<XElement>().And.HaveAttribute("attr", "1");

I've run into quite a few of these scenarios in which this chaining would make the unit test a lot easier to read. But, as usual, don't overdo it.

Another little improvement is that you can now assert two XElement objects and their children for equality. Granted, it's a first implementation, but know that we're working on supporting a more advanced implementation that will ignore the order of attributes, whitespace and other typical non-relavant XML junk.

So what's planned for 3.1? Well, Oren (Novotny) already provided me with a pull request for supporting Windows Phone 8.1 (the Windows Runtime based). And as soon as Maarten completed support for Visual Studio 2013 Update 2 on the CodeBetter TeamCity server, I will move the XML-specific parts of the PCL library in a Shared Project. This should fix the current requirement to target .NET 4.0.3. So if you can't wait for the official release, add our MyGet feed as a NuGet Package Source and start testing against the latest commits.