Martin Thompson (@mjpt777) and Todd L. Montgomery (@toddlmontgomery) discussed the state of the software industry at YOW! 2014, including “barbequing” a whole herd of sacred cows. (Slides)

A Dr Dobbs 2010 report into IT project success showed a correlation between higher numbers of people on a project and higher rates of failure. Even the best performing methodologies still have >10% failure.

A Gartner report shows a correlation between the amount of money spent on a project and the likelihood of failure. Yes, the more money ploughed into a project, the more likely it is to fail! (Having looked at the data, the difference was actually only a couple of %)

When LMAX started open sourcing stuff, recruiting became really easy, to the point where they didn’t even need to advertise.

They questioned whether Product Owners – people running a project but who aren’t part of the business – are useful, and suggested what you really need for a project to succeed is a business expert who’s invested in the project’s success, but also busy being heavily involved in the day-to-day running of the business.

Technologists (Software Development, Testing and Operations groups) need to stop talking about “them and us”, and stop talking about solving people’s problems. Instead, they should realise they are part of the business, and take responsibility for the ROI they deliver.

In discussing getting rid of shared mutable state, they recommend considering “no update” databases, something we’ve been doing more and more of at Tyro the last few years. This basically means banning the use of the UPDATE statement so that your database becomes a record of new facts discovered over time. The current state is easily found by looking at the most recent facts, but the key properties are that information about the past is never lost (unlike with UPDATE statements) and contention over the database is typically easier to manage.

They recommended everyone with an interest in performance read up on Universal Scalability Law (USL), a newer model of calculating the limit of concurrent scalability that subsumes Amhdahl’s law.

They mentioned that, in their work helping other teams fix their performance problems, protocol translation to and from text is a regular cause of performance problems. Consider binary protocols instead.

They brought up the hotness of microservices, and delivered one of the quotes of the conference:

“Synchronous communication is the crystal meth of distributed software.”

It’s easy and feels good, but it’s very bad for you in the long run. Why? Because of temporal coupling. A great analogy they put forward: “Do you stand next to your letter box when you’re waiting for a reply?”

They asked “What’ is the biggest problem with functional programming?” and offered the answer “Functional programmers!”

They claimed to debunk the myth that functional programming is the solution to multi-core. Can’t remember the arguments here, unfortunately.

They said many Ops teams are still motivated to avoid changes (based on the goals the company gives them). Instead, the companies should be motivating them to optimise for speed of delivery.

Virtualisation adds a cost! If you’re in a performance-sensitive environment you need to consider if it’s worth it.

They finished off discussing the state of diversity, in particular gender diversity, in the industry, and showed this chart of the percentage of female majors in CS courses decreasing steadily from 1985 onwards.

The source story has some interesting discussion, including an assertion that PCs became widely available in about the mid-80s and were mostly marketed at boys, ingraining a “computers are for males” mentality in the public. There’s also some research indicating that families with boys are more likely to buy computers than those with girls, and that CS teachers eventually began assuming home ownership of a computer and experience with programming, something that was less likely to be true for female students.

We discussed this topic in our group of Tyro developers at lunch time, including one of our female colleagues (who confirmed her family had a computer growing up). I found speaking about the issue with others crystallised some things I’ve been thinking about for a while, and I realised there are actually two separate issues: women not choosing IT in the first place, and then women who’ve chosen IT leaving it. Both issues are bad for the industry in general, and companies with low diversity in particular, because diversity has been shown time and time again to be correlated with successful teams.* The second issue – women choosing to leave IT – is very worrying if it suggests that we have an industry that is generally unsupportive of women. I’ve read about a number of women’s negative experiences on the web, though always in the USA. Could this be because Australia has less of a problem in terms of women not being accepted in IT? Or have I just been fortunate enough to work in some of the few places where it isn’t a problem? If anyone has any Australian-based research on gender diversity in IT, I’d appreciate being pointed to it.

* For two examples of gender diversity research, see ‘The Case Against the All-Male Startup’ on Inc and ‘What makes a team smarter? More women.’ on HBR. Google can get you to plenty of other research.