ASWEC Day 3 (SE Education Track), Keynote, “Teaching Gap: Where’s the Product Gene?” (#aswec2014 #AdelED @jmwind)

Today’s speaker is Jean-Michel Lemieux, the VP of Engineering for Atlassian, to open the Education track for the ASWEC Conference. (I’m the track chair so I can’t promise an unbiassed report of the day’s activities.) Atlassian has a post-induction reprogramming idea where they take in graduates and then get people to value products over software – it’s not about what’s in the software, it’s about who is going to be using it. The next thing is to value experiences over functionality.

What is the product “gene” and can we teach it? Atlassian has struggled with this in the past despite having hired good graduates in the past, because they were a bit narrow and focused on individual features rather than the whole product. Jean-Michel spoke about the “Ship-it” event where you have to write a product in 24 hours and then a customer comes and pick what they would buy.

Jean-Michel is proposing the addition of a new degree – to add a product engineering course or degree. Whether it’s a 1 year or 4 year is pretty much up to the implementers – i.e. us. EE is about curvy waves, Computer Engineering is about square waves, CS is about programs, SE is about processes and systems, and PE is about product engineering. PE still requires programming and overlaps with SE. Atlassian’s Vietnam experience indicates that teaching the basics earlier will be very helpful: algorithms, data structures, systems admin, programming languages, compilers, storage and so on. Atlassian wants the basics in earlier here as well (regular readers will be aware of the new digital technologies curriculum but Jean-Michel may not be aware of this).

What is Product Engineering about? Customers, desirable software over a team as part of an ecosystem that functions for years. This gets away from the individual mark-oriented short-term focus that so many of our existing courses have (and of which I am not a great fan). From a systems thinking perspective, we can look at the customer journey. If people are using your product then they’re going through a lifecycle with your product.

Atlassian have a strong culture of exposure and presentation: engineers are regularly explaining problems, existing solutions and demonstrating understanding before they can throw new things on top. Demoing is a very important part of Atlassian culture: you have to be able to sell it with passion. Define the problem. Tell a story. Make it work. Sell with passion.

There’s a hypothesis drive development approach starting from hypothesis generation and experimental design, leading to cohort selection, experiment development, measurement and analysis and then the publishing of results. Ideally, a short experiment is going to give you a prediction of behaviour over a longer term timeframe with a larger number of people. The results themselves have to be clearly communicated and, from what was demonstrated, associated with the experiment itself.

Atlassian have a UI review process using peer review. This has two parts: “Learn to See” and “Learn to Seek”. For “Learning to See”, the important principles are consistency, alignment, contrast and simplicity. How much can you remove, reuse and set up properly so the UI does exactly what it needs to do and no more? For “Learning to Seek”, the key aspects are “bring it forward” (bring your data forward to make things easier: you can see the date when your calendar app is closed). (This is based on work in Microinteractions, a book that I have’t read.) The use of language in text and error messages is also very important and part of product thinking.

No-one works alone at Atlassian and team work is default. There’s a lot of team archeology and look at what a team has been doing for the past few years and learn from it. The Team Fingerprint shows you how a team works, by looking at their commit history, bug tracking. If they reject commits, when do they do it and why? Where’s the supporting documentation and discussion? Which files are being committed or changed together? If two files are always worked on together, can we simplify this?

In terms of the ecosystem, Atlassian also have an API focus (as Google did yesterday) and they design for extensibility. They also believe in making tools available with a focus on determining whether the product will be open source or licensed and how the IP is going to be handled. Extensibility can be very hard because it’s a commitment over time and your changes today have to support tomorrow’s changes. It’s important to remember that extending something requires you to build a community who will use the extensions – again, communication is very important. An Atlassian platform team is done when their product has been adopted by another team, preferably without any meetings. If you’re open source then you live and die by the number of people who are actually using your product. Atlassian have a no-meeting clause: you can’t have a meeting to explain to someone why they should adopt your product.

When things last for years you have to prepare for it. You need to learn from your running code, rather than just trusting your test data. You need to validate assumptions in production and think like an “ops” person. This includes things like building in consistency checks across the board.

Where’s the innovation in this? The Atlassian approach is a little more prescriptive in some ways but it’s not mandating tools so there’s still room for the innovative approaches that Alan mentioned yesterday.

Question time was interesting, with as many (if not more) comments than questions, but there was a question as to whether the idea for such a course should be at a higher level than an individual University: such as CORE, ACDICT, EA,or ACS. It will be interesting to see what comes out of this.