DDD 2018 at Microsoft Reading

After a busy July, finally I’ve got a quiet moment to catch up with my notes from the recent Develop Developer Developer event held at Microsoft HQ in Reading.

I attended a real mix of sessions this year. First up was a real mind bending session led by Francess Tibble and Anita Ramanan, two software engineers at Microsoft talking about Quantum Computing and the Q# language. The session was split into two parts, the first a bit of a crash course in the physics involved in Quantum Computing, with quite a bit of maths too. The interesting take away is that present day quantum computers are expensive and unstable as they are particularly sensitive to external factors so can lose state in seconds. As a result we currently have the Quantum Development Kit that simulates how a real quantum computer should behave.

The key difference with a quantum computer is in the bit, in classical computing the bit is ether 0 or 1, but in quantum computing the bit can also be any point in between, taking the usual light bulb analogy for a classic bit, it’s like having a dimmer attached. I really haven’t got the space to cover all their content in detail, but they did do a version of the same talk a few days before DDD which is online on YouTube.

Moving on I then attended Joseph Woodward talking about Web Assembly, Blazor and the Future of Web Development.

Joseph started with a run through of the history of web development, and the perennial problem that whilst there has been a relentless move towards providing applications in a web browser, the tools to create rich applications in a web browser are really pretty limited. JavaScript, the main language of the web has become that largely by historical accident, and is pretty slow. Web Assembly is the latest of a number of attempts to replace JavaScript as the language of the web, in this case providing what is effectively a low-level byte code for the web and then compiling other languages into this byte code. At this stage it’s still very much a minimum viable product, but does seem to show some promise with multiple languages being able to compile into Web Assembly byte code.

For C# and other .Net support, since they also compile into the intermediate language of the .Net platform, Microsoft offers Blazor, which is a full .Net machine written in Web Assembly byte code. This of course does mean that .Net intermediate language is then being interpreted into Web Assembly byte code, so there are plans to compile to avoid this double layer of interpretation.

The actual coding is familiar to any C# programmers with familiar dependency injection, and the ability to pull in code using Nuget. Interop with JavaScript is provided, and is necessary because Web Assembly does not provide access to the DOM.

It was clear from the talk that the platform is still immature, it lacks performance and has no threading or garbage collection. However it does show promise. Even if it doesn’t provide a replacement for JavaScript, it does allow us to mix and match languages picking the language that is best suited for a particular task.

Next was what for many people was one of the big draws for this years DDD, the return of Barry Dorrans, now .NET Security Curmudgeon at Microsoft, but who before joining Microsoft and moving across the pond had been a regular speaker on security at developer events. Barry was presenting his Code Behind the Vulnerability session, variations of which he has presented for a number of years at conferences around the world. The great advantage of presenting it here however is that it allowed developers who don’t work for companies with the budgets to send their developers to paid for conferences to see this important session. Indeed Robert Hogg CEO of Black Marble who organise the DDD event at Microsoft considered the subject matter so important that he said to any of his developers in the room that they’d be fired if they did anything that Barry had spoken about!

The purpose behind the Code Behind the Vulnerability session is basically to go through security issues that Microsoft have found in their code, and the cause so other developers don’t make the same mistakes. Barry updates this session periodically as new exploits and problems come to light, so it is well worth keeping an eye out online for new versions.

Barry covered eight different security advisories, including hash tables that could bring a system down if they received specific user data – the tip here being not to use user supplied data as keys for a hash table, exposed endpoints that allowed users to work out encrypted messages, and a number of occasions where people had turned off or misused features making security holes, for example turning off signing on view state allowing attackers to create .NET objects, or simply writing a GET API call that changes state.

Barry’s summary slide is the basics, but the whole slide deck is worth a read. His summary is:
– Sign your data, even when it is encrypted
– Don’t use regular expressions
– Don’t use BinaryFormatter
– Don’t overbind in MVC
– Use the right HTTP verb
– Validate your inputs

Barry’s session is a critical one for anybody doing .NET development, many of the issues he shows are easy to make, but can have catastrophic consequences.

The next session I attended was rather lighter, but was also one that has been presented at a major conference but Dylan Beattie was bringing to DDD. You can view the keynote version of Apps, Algorithms and Abstractions: Decoding our Digital World on YouTube and it is broadly similar.

Dylan starts off with talking about how news of his birth and a first picture made it from where he was born in Africa, back to his grandparents back in Oxfordshire – a process that took weeks. He then looks at technology today where we can get a photo appear on a phone in your pocket and respond immediately. In the space of his lifetime the way we communicate has fundamentally changed. His session goes through the basic technology that underpins these changes, and is absolutely fascinating.

This was probably my favourite session of the day as it covers so many different areas of technology. It was also presented in an easy to digest way, and in a way that I’ve been able to show it to my children and they can start to understand all sorts of technological ideas.

My final session was one of those I picked more because I enjoyed the speaker – Gary Short talking about AI Dev-ops. Gary started looking at how the principles that have brought about dev-ops can be applied to AI and machine learning work, for much the same reasons. There has always been a big disconnect between data scientists and coders. Data scientists have a very niche skillset, so in the past they would do the specialist work, and then hand their carefully designed models to developer to implement. However tools are now being produced that allow data scientists to develop an implement their models, and coders to just connect to these rather than implement them.

Gary also had some useful tips, he highlighted that you can only optimise algorithms for false positives, or false negatives, not both, so it is a business decision as to which costs more, false positives or false negatives. This is a useful tip with regards to our products at FISCAL as we have a continual tension between reducing the number of false positives we produce, whilst not missing results, i.e. a false negative.

In summary DDD 2018 was a good day, and well worth spending a Saturday. For many developers there isn’t the budget to go to paid conferences regularly, so it is particularly good to be able to see sessions from those conferences presented live at a free community conference. Particularly for sessions like Barry’s important information about how to code securely is something all developers should be hearing, not just the ones who work for a company with a good training and conference budget!

Something a Bit Different

We’ve just finished watching the Royal Wedding of Prince Harry and Meghan Markle, and whilst in some ways it was business as usual with all the processions and pageantry, in others this was a pretty radical departure.

In terms of the service, despite the fact that vast majority of Church of England weddings are conducted using the Common Worship service, the Royals would invariably use the traditional Book of Common Prayer wedding service or the Alternative Services Series One update, with an understanding and explanation of marriage that is totally at odds with what most people these days think a marriage is about.

Compare the introduction that was used at the wedding of the Duke and Duchess of Cambridge, or the Book of Common Prayer introduction with the modern introduction that Harry and Meghan had today – traditional is primarily about children, and a “remedy for sin and to avoid fornication” in the BCP version, without any mention of love which is first in the introduction to the modern service.

As to why the Royals always go for traditional, you need look no further than Prince Charles who is patron of the Prayer Book Society which makes it all the more amazing that his younger son used the Common Worship service straight out of the book, even with the contemporary language Lord’s Prayer. The choice of hymns and anthems too was pretty much what many regular couples would pick, without any special commissions – a couple of well known hymns, anthems both of which are in the repertoire of our church choir in Finchampstead, indeed The Lord Bless You and Keep You is one that pretty well any church choir in the country will know.

Where it differed from what most couples would have, and was very different from your average Royal event was the choice of preacher. Back in 2001, the Duke and Duchess of Cambridge had the then Bishop of London, a great friend of Prince Charles. Harry and Meghan apparently asked the advice of Justin Welby, the Archbishop of Canterbury and he recommended Michael Curry, the Presiding Bishop of the US Episcopal Church. Bishop Curry is regarded as one of the best preachers in the Anglican Church, but is also pretty controversial with the traditionalist elements of the Anglican church, and indeed with the current US Government. He preached what for him was a short sermon at the wedding – check out some of his other sermons on YouTube – but something quite unlike anything we’ve seen before.

If you want to see quite how different, this is the sermon the former Bishop of London preached for the Duke and Duchess of Cambridge – I had no recollection of what he actually said when I looked back:

This is the sermon Michael Curry preached today – complete with quotes from Martin Luther King, quotes from a slave song, talking about poverty, world peace, and the power of love, but delivered in a style no English Bishop would ever have attempted, let alone in a Royal Wedding.

There has not surprisingly been a lot of reaction. This from radio presenter James O’Brien:

This from Labour MP David Lammy:

TV Presenter Piers Morgan:

Actor David Schneider:

And Zara’s face was a picture…

Finally we have Archbishop Justin and Presiding Bishop Michael talking about the sermon outside St Albans Abbey tonight.

Ultimately Curry had an audience of billions, and probably the only chance he’ll get to speak to an audience that large. Unlike any other Royal Wedding before, he actually preached a sermon with a message rather than the usual fairly light fluffy wedding sermon we’d expect, and certainly I doubt we’ll get anything like it at the next Royal Wedding in the autumn.

Open Space at Pivotal Software

Yesterday I had my first Unconference experience, where I attended a one day Open Space event, held at the offices of Pivotal Software, who are located just off Silicon Roundabout, on Old Street in London.

Firstly it’s probably worth explaining the concept of an Unconference or Open Space. The organisers of this event described it well when they said that the concept of the Open Space came about when people observed that many of the interesting conversations at other conferences took place in the coffee breaks, so when I arrived, the conference organisers had arranged a number of different rooms and environments, had divided the day up into a number of time slots, but all we had was a large empty wall to fill with sessions and activities, and sheets with the four principles, and one law that would govern the day.

Looking at the principles, the first three are about how the sessions run, basically don’t worry about who is or isn’t there, take the session as it comes, and don’t feel you have to fill the time slot:

  • Whoever comes are the right people.
  • Whatever happens is the only thing that could have happened.
  • When it’s over it’s over

The next principle is “Butterflies and Bumblebees”, which describes the way some people move between sessions. The Bumblebees don’t spend an entire period in one session, and instead visit many of the groups and sessions, cross pollinating between the sessions with fresh views and ideas they have maybe picked up from other sessions. Butterflies are not participating in any current session, but instead are tending to their own needs, but sometimes participate. At the Open Space both character types were apparent during the day.

The one and only law is the Law of Two Feet – basically if you’re not learning, or not feeling you’re gaining anything from the session, just walk away.

Wikipedia has a much more detailed overview of the technique – whilst we were using for a technical conference the technique could easily be applied to any subject area.

We kicked off with an ice breaker session to break us up into five groups to discuss sessions where we had to arrange ourselves into alphabetical order based on our country of birth. That proved to be an interesting exercise for several groups – the people from the United States actually all put themselves under A for America, I was in a group of three for England, but there were other English people down in a group at U for United Kingdom, and there was a lady who put herself at C for Crimea because she didn’t want to offend anyone, given that when she was born Crimea was in the Soviet Union, has been in Ukraine for a long period and Crimea has now been annexed by Russia.

In our groups we then talked a little about what we wanted to gain from the day, and then discussed what possible sessions we could do. There was an interesting mix. Firstly, some people had existing sessions they had done elsewhere that they were willing to run again – with hindsight I actually had one of those in that I had a copy of a Software Craftsmanship brown bag I’d done at work on my laptop – something for next time. Other people had current project they were happy to share and talk about with other participants, or skills they were willing to share. Other sessions were encouraged in the group discussion on sessions, so for example in our group we had a man who worked as a Biological Scientist, and was happy to talk about his work with scientific software. One key driver is that you don’t need to be an expert to propose a session, so several people had topics they wanted to talk about ranging from particular technologies or concepts, challenging principles, or just hot topics they wanted to discuss.

From there everybody with a proposed session lines up to give a quick elevator pitch of their proposal and suggest a location, taking in turns until all the sessions have been proposed. After that there is a rationalisation stage where sessions can be moved to resolve any potential clashes, to balance out the schedule, and refine a better schedule. After that it was into the first session.

The first session I picked was one on Unconditional Programming. The concept comes from Michael Feathers, whose superb book on Legacy Code actually sits on my desk much of the time. He came up with the term in a blog post back in 2013 and he has done conference talks on the same subject. It’s certainly an idea I’d come across previously, and the concept of Unconditional Programming is potentially one of the techniques Feathers discusses in his upcoming book which was originally going to be called Brutal Refactoring: More Working Effectively with Legacy Code, but may well be called Unconditional Programming.

The basic concept is that in many cases the use of conditional code such as the ubiquitous if/else construct actually couples different bits of the code together that shouldn’t be coupled, so removing the conditional will result in two separate more easily testable pieces of code that a cleaner and more easy to understand.

This provoked an interesting discussion, as the conditional is not really removed, it is merely moved, so rather than existing as an if statement the conditional is being provided by polymorphism in the factory class.

In the discussion we also had a few proponents of functional languages, one who uses Erlang, and another who uses Haskell who agreed that conditional free code was easier to achieve in functional languages, in particular through the vehicle of pattern matching. In this situation the pattern matching is providing the conditional rather than the if statement.

It was certainly an interesting discussion, especially with a mix of developers from both imperative and functional programming backgrounds.

My next session was given the title “How to produce your own Citymapper in 10 Minutes”, and was a developer who as a side project had been looking at routing algorithms and had been using London Underground routing as a test bed.

He started off showing us a picture of the London Underground map, and then highlighting that if you change the stations into nodes, and the lines between them into edges, you have a familiar concept in Computer Science, a directed graph. He highlighted that finding the shortest route in a directed graph was a problem that had been solved way back in 1956 by Edsger Dijkstra, and as such libraries to generate the shortest routes were available in pretty well every programming language. He then showed us some code that used the freely available underground station data that you can get from the TFL API and Dijkstra’s algorithm to work out the shortest route between two stations on the underground.

We then had a wide ranging discussions about how it wasn’t quite that simple, looking at issues of fast trains on lines like the Metropolitan line, and that it didn’t take account of the times to change trains. It was also highlighted that Dijkstra’s algorithm quickly breaks down with larger datasets, even if you use intelligent heuristics to prune potentially unsuitable routes that go away from the destination.

We then finished off talking about better options for graph and tree searching, and got onto talking about the A* algorithm that can produce routes more quickly, and especially a recent talk by Simon Peyton-Jones that covers the same subject area called Getting from A to B – Route Planning on Slow Computers.

My first session after lunch was entitled “Beyond SOLID” and was proposed by a developer who wanted to challenge whether the SOLID principles were really the best way to describe Object Oriented code.

We started working through each of the principles.

Firstly he stated that he though that the Single Responsibility Principle was primarily about code cohesion, and could equally be applied to other programming paradigms – it was something that was just good practice rather than something specific to Object Oriented Code.

Moving on to the Open/Closed Principle, he again thought that whilst the principle of being open for extension and closed for modification is primarily about plug ability of code, and is really a bit vague and doesn’t tell us much that is valuable.

The Liskov Substitution Principle he thought was probably one of the most difficult to understand of the principles, and whilst it gives us a better paradigm for understanding what object oriented code should look like is again not specifically about object orientation.

The Interface Segregation Principle is also about cohesion of code, but this time is more object oriented as it is specifically talking about contracts, using interfaces rather than concrete classes.

Finally the Dependency Inversion principle is again more object oriented as it is about how we use interfaces to instantiate concrete classes.

We then opened the discussion, and there seemed to be consensus that the SOLID principles were more principles of good design rather than specifically object orientation principles. We also discussed how being able to regurgitate the SOLID principles was almost a staple interview question, but it really didn’t indicate anything much beyond the interviewees ability to remember the acronym. It was also pointed out that SOLID has quite a mix of high level design principles, low level concepts, some architecture, and in the Liskov Substitution principle some quite deep Computer Science.

From there we tried to look at other principles or concepts that could describe Object Oriented coding including Design Patterns, Tell don’t ask message passing, CQRS command query segregation, keeping things small/replaceable parts, balanced abstractions, loose coupling, tight cohesion, code smells, and the classic OO principle of polymorphism, encapsulation, and inheritance/abstraction.

However when we looked at those principles, very few of them exclusively applied to Object Oriented code, many of them were just good design practices.

As with the earlier discussion on Unconditional Programming it was a good discussion about something that in many circles is regarded as a foundation of Object Oriented programming, but it is clear once you dig into it, certainly doesn’t cover all of Object Oriented programming, and is much more about good design than anything Object Oriented specific.

The next session I went along to had been convened by a developer and a mental health practitioner who were concerned about issues of developer mental health and burnout, and was a wide ranging discussion amongst a group of developers over work cultures, work pressures and how developers cope, or don’t cope with them.

From the discussion there certainly seems to be some variation in how companies handle their developers. Some will take all the hours developers will give with apparently minimal concern for their mental well being, at times actively encouraging and rewarding long hours that can lead to burnout. Others although they are good on limiting actual work, encourage their developers to be participating in their own time in community events and side projects, which again are increasing stress – several said they are now careful to limit their participation in communities to ones they consider directly relevant to their work.

We also had a good discussion about practices in our teams, covering working hours and stand up times. One company a developer worked for the director would actively force developers to go home at about 6pm. Another deliberately did not give their developers laptops and limited remote access to stop developers working long hours. Another operated a hot desking policy that used fixed desktop computers at each desk and the developers moving around and pairing. This also highlighted that pairing forces people to work common hours – one company explicitly banned using any code that hadn’t been written in a pair.

This again was a very interesting session highlighting the different ways different teams worked, and highlighting good practice, and bad practice across those different companies.

The final session was again a discussion on the broad topic of exploring where software development overlapped with other disciplines.

We started from the principle that the Software Industry has tried a number of metaphors over the years for describing itself such as Engineering or Craftsmanship, but we quickly reach the limits of those metaphors.

Over the course of the hour we drew connections with at least twenty other areas and disciplines including Philosophy, Biosciences, Psychology, Linguistics, Politics, Art and Design and Sociology.

Once again, with a diverse group of people it was a good exploration of all parts of software development drawing some parallels I’d not really though of before.

After that the day drew to a close with a quick retrospective where we sat and talked and shared experiences about what we had learnt during the day. As a first experience of an Open Space it was really enjoyable, from turning up with no idea of what I might learn there were a wide variety of sessions, and as the facilitators said at the beginning lots of interesting discussions.

Unlike other conferences I’ve been to, there was a pretty diverse range of participants also, with much closer to a 50:50 male to female split than I’ve seen elsewhere. Much as with DDD Scotland where one of the most interesting sessions was the Lean Coffee discussion, we got a chance to talk and explore ideas that you maybe wouldn’t see as a full session in a regular conference.

My thanks go to Denise and Spike at Pivotal Software for providing the venue and organisation for the event, and all the other participants for making it such an enjoyable day.

Thoughts from, and the lives of a Canadian and a Brit living in Southern England.