Domain-Driven Design: Hidden Lessons From the Big Blue Book
devopsdays Rome
1. Trents bizarre devopsdays talk
• Linux systems admin
• Really bad coder
• MySQL DBA
• Enjoy working with my mates and having fun
• Trying to do webstartups
– Has anyone seen enterprisejenkins.com!?
- Want to tell you a story about the company I work for
Africanns – twenty realestate.com.au is ne of the biggest Australian websites- property advertising website -home owners wanting to sell pay to list their property on the site- In Australia 1b spent on a year on property advertising- – three years ago 90% of that was spent on print media – *don’t quote me on that!
Welsh – 19Three years ago we came to the realization that print was deadWe hadnt released any new features or products – we have to do something as 1 billion is a big opportunity - our shareholders demand that we do something!
Romanian – 18So there were mass changes at the executive level- when youre a public company and youre sales orientated, you’re driven to make more money through new products and whatever- when you’re making double digit growth, the market depends you keep making double digit growth
indonesian– 17moving from waterfall development aka no development to agile for backend systemwe’re split into two - backend systems – that take listings from realestate agents- front end – which is the realestate.com.au websitepurchased an off the shelf solution for our “front end website’ from a vendor in the US
swahili– 16Vendor solution is java- vendor solution was yellow pages site product– re-skinned and customized for real estate listings- the vendor would ship us a war file every week or so with changes we wanted - so we finally released an updated version of our site – which looked pretty cool
georgen– 15But the site wasn’t perfect- but the problem with having a vendor in the US and some developers in Australia is the timezone difference- if we wanted to make an new feature or worse, flag a bug with the site, there would most likely be a two day turn around to flagging something to having it acknowledged
czech– 14Even worse, was that after the developers signed off their backend changes- and the vendor signed off their code, it will be hand balled to the ops guys to deploy- everything was manual and tedious and error prone we were the first company to run the vendor solution at some type of scale-- yeah, those mysql nested subqueries performed like shit after 10,000 entires
polish– 13A release was akin to a space shuttle lunch it would take ½ day to release the vendor solution- everything was manual and tedious – though releases involved the developers (backend end systems) and ops guys- was good to build that relationship between ops and devs
estonian– 12Most of the complexity was around the manual tedious release process At a high level, to make things faster, its just cheaper to hire more people – more operations people- didn’t speed up the deployment activities but ensured there was capacity from others when a deployment took place
norwegean– 10So over a year had past since we went down the vendor solution – and we smashed the marketExecs are getting a little itchy that next year wont be as profitable as anotherwe have a fuck load of money to play withCan we throw cash at the solution to move faster
latvian– 9Purchased the vendor solution code- hire some of the vendors developers – relocated them to melbourneWe bought the code facilitate communicationwe wanted more products, we wanted to hire more developers
german– 8How many good ruby and java devs are in a city of 4millionNot as many as we needed looked at outsourcing some of the development – to increase throughput pair with someone that had the same cultural values as us – thoughtworks- outsource somewhere in a similar timezone!
Finnish– 7- instead of having a china team working on a productWanted to integrate the china guys by having half a team of say 10, having half the guys in china and half in Melbourne- virtual card walls - always on skype video chat on big lcd screens- regular tech swaps between melbourne and china
danish– 6- Always on skype sessions and tech swaps built the relationships within the team-having part of the in another country really forced communication for successIts not “us” and “them” – its we – we all win or we all loose
5 dutchSo via distributed agile our development throughput increased Though we were still a little slow because code was being thrown over the wall So given we have a lot of ops guys, lets embed the guys in each team and have take ownership of the full lifecycle from coding to release
4 FrenchWhat we then found was we were developing more things and releasing faster but what we found was we didn’t have the business context of what were were doingWe didn’t know that there was revenue attached to some products, and if so how muchRestructure teams around business unit and embedded the business guy in the teams for that business communication
3 spanishSo now in a team of 10, 1 IM, business guy, developers and operations guysWe’re all communicating with one another, having shared goals and accountability, understanding strengths and are trying to all archive the same thing
2 - italianIve been counting down from 20 in different languages without that context and shared understanding you may not have picked that upWhich I think is very similar to non collaborative function units in an organization
engilsh From my experiences with the changing landscape at realestate.com.au when you’re communicating talking the same language, you’re winning.