Techique, Methodology, Culture
•Download as PPTX, PDF•
2 likes•526 views
AutoCAD 360 lessons learned on building an efficient development team.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Techique, Methodology, Culture
Similar to Techique, Methodology, Culture (20)
Recently uploaded
Recently uploaded (20)
Techique, Methodology, Culture
- 1. Technique, Methodology, Culture Benny Bauer Software Architect, Autodesk benny.bauer@autodesk.com @benikbauer
- 6. AutoCAD 360 Backend 2008 Created 200K LOC Technology Java, Tomcat, MySQL
- 8. Phase 1: RPC AutoCAD 360 API Evolution RPC
- 9. HTTP Adapter Servlet Phase 2: Adapter Servlet
- 12. Logical endpoints HTTP methods Versioning Json payload HTTP Phase 3: RESTful APIs
- 13. Monolithic Architecture - Cons Hard to keep modular design Full application deployment even on minor change Scaling is horizontal Large code base is scary Hard to adopt new technology Hard to scale development
- 14. “Microservices are small, autonomous services that work together…” Introducing Microservices
- 15. “… built around business capabilities and independently deployable by fully automated deployment machinery” (“Building Microservices” by Sam Newman) Definition – continued
- 16. “…There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” (“Building Microservices” by Sam Newman) Definition – continued
- 19. Increased Operational Complexity Build, Testing, Deployment Monitoring Maintenance Distributed System Complexity Network latency Asynchronicity Fault tolerance Message serialization, versioning Microservices - Cons
- 20. Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. -- Melvyn Conway, 1967 Conway’s Law
- 21. Next phase: Serverless Architecture?
- 23. Release to production at any time! Why? Get feedback soon & often Frequent deployments -> Smaller changes -> Lower risk Developer happiness *Etsy: “Optimizing for developer happiness” Methodology #1 - Continuous Delivery
- 24. HOW? First you need Continuous Integration Continuous Delivery Commit Build Test Store Artifact
- 25. Then you can deploy Continuous Delivery and monitor!
- 26. Methodology #2 – Data Driven
- 27. Production stability Performance Exceptions Builds stability Usage analytics Data Driven
- 28. Data Driven
- 29. Be deliberate Requirements – How the feature will be measured Design - How performance will be measured Tools: Statsd & Grafana, New Relic, Splunk Paint the walls with dashboards Data Driven
- 30. We start with a Walking Skeleton: Make something work end-to-end Wrap it with CI Now, add more meat Methodology #3 – Walking Skeleton
- 31. We strive to have maximal test coverage: New code – mocking & dependency injection Legacy code – only changes are tested “Aggressive mocking” when no other choice Methodology #4 – Testing
- 33. Methodology #5 – Code Reviews Better Correct Clean
- 34. At least 2 reviewers Done within 24h Asynchronous & Documented (“code collaborator”) Frequent & Small Code Reviews
- 35. Start with a walking skeleton Confirm functionality with testing Increase quality with code reviews Get insights and drive actions from data Wrap it all in Continuous Delivery Methodology Summary
- 37. Autodesk TLV
- 38. What is Culture? If methodology is the how, then culture is the why
- 39. Culture evolves naturally, but hacks can give it a boost
- 40. “Building a Dream Team” Culture #1 – Stating our Vision
- 41. PYTA (Pick Your TAsk)
- 42. PYTA (Pick Your TAsk) It got us to Apple’s keynote
- 43. Bazinga!
- 44. Guilds
- 45. A group of people that work on the same technical domain and will love to spread the knowledge internally and externally Guilds
- 46. Guilds Master: A guild leader, preferably not a manager Sponsor: Master’s go-to guy Activities: Organizing Meetups Shared projects “Army reserve” Sharing knowledge Brainstorming Mingling
- 47. Open Source
- 48. Blogging
- 52. Questions?
- 53. Thanks
- 54. Autodesk is a registered trademark of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product and services offerings, and specifications and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document. © 2015 Autodesk. All rights reserved.
Editor's Notes
- https://www.pinterest.com/pin/436567757599701896/
- Photo: http://actioninsolitude.com/climbing/nate-moore-climbs-32-5-12s-32nd-birthday-red-rock-canyon-las-vegas-nevada/
- To be a good rock climber you need to have technique, physical strength, and mental strength. All are necessary. Making the analogy to Software development…
- Making the analogy to Software Development, I’d say there are 3 pillars of efficient development *team*: The 1st is Technique (and by technique I mean technical skills, technology, architecture & design), The 2nd is Methodology (no matter how small is the team, there has to be some process in place) And of course Culture (what I see as the behavior compass of the team). In this session I’ll try to cover these 3 aspects by sharing some of our lessons of building AutoCAD 360 cloud services. We’ve been developing AutoCAD 360 for over 7 years so we have many mistakes to share
- More background on AutoCAD 360 backend: It exists since 2008, over the years it grew to over 200K lines of code and it’s written in Java running on Tomcat and using MySQL DB.
- So let’s start from the technique pillar, in which I’m going to focus on the some architecture mistakes we’ve done.
- The second story is about our backend API evolution. Phase 1 – RPC: Originally, back at 2009, our first client was Flash, so we used Red5 server, which is an open source Flash media server. It provided a flash RPC protocol (RTMPT) which made our life easier – no need to develop APIs or Servlets. But when we wanted to develop our first mobile app (iOS), we couldn’t use the flash protocol anymore so we had to build a classic web server with servlets.
- Phase 2 – HTTP with “Adapter” Servlet: Once we wanted to develop our first mobile app (iOS), we couldn’t use the flash protocol anymore so we had to build a classic web server with servlets. Which meant building a servlet for almost every rpc we had back then. So, to avoid it we came up with a brilliant idea – we’ll have one central servlet, which will receive the function name and parameters serialized altogether, and with reflection it will direct to the appropriate execution on the server. We named this servlet as the “Adapter” servlet. When we wanted to add new api, no additional interface work was needed. Amazing!
- But as you may have already realized there were significant drawbacks with this approach: Impossible to monitor performance of web transactions with tools such as New Relic It adds technical debt because it’s harder to keep the code modular
- But as you may have already realized there were significant drawbacks with this approach: Impossible to monitor performance of web transactions with tools such as New Relic It adds technical debt because it’s harder to keep the code modular So eventually we’ve realized that what seemed like a “genius” hack at the time is a major technical debt at present. And instead we started developing RESTful APIs Image: http://www.hiringthing.com/images/blog/ball.png
- Phase 3 – RESTful APIs: So eventually we’ve realized that what seemed like a “genius” hack at the time is a major technical debt at present. And instead we started developing RESTful APIs: Clear API separated by logical endpoints Using HTTP methods Easily supports versioning Payload can be simple as Json http://enginyoyen.com/wp-content/uploads/2015/01/the-monolith-monster.png
- But even with RESTful apis we still have a monolith, which means that: It’s hard to keep modular design Deployment - changes in one API require FULL application deployment Scaling - Impossible to scale out specific API Large code base is scary It’s Hard to adopt new technology It’s Hard to scale development across teams http://enginyoyen.com/wp-content/uploads/2015/01/the-monolith-monster.png
- Small Autonomous – running on separate process, can be deployed separately, can be scaled separately Work together – have lightweight communication (HTTP for example)
- Centralized management – Service discovery
- http://www.slideshare.net/Pivotal/arch-forcd-microservices
- Phase #4 – Microservices: Microservices are a solution for these problems.
- Operational complexity – requires more investment in devops. Docker to the rescue for deployment? Distributed System Complexity – Introducing more REST or messaging between processes (tasks example) Pitfalls: Network latency, fault tolerance, message serialization, unreliable networks, asynchronicity, versioning, varying loads
- Example: full stack vs. specific domain team (client, server) remote teams It means that you can grow your organization with microservices because it’s easier for more teams to own services
- http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html
- The next pillar is Methodology. But before going there, let’s have a quick refreshment
- https://www.pinterest.com/goerp/toons/
- Paint the walls, be transparent, every open space has a tv presenting the dashboards
- We’re trying to be more driven by data than feelings. And it relates to Monitoring stability Performance Exceptions Usage
- It’s a great satisfaction to visualize the impact of your code changes, as with this screen shot from our grafana where we can see the db traffic reduced significantly after some optimisations.
- We’re trying to be deliberate about it - planning wanted metrics should be part of the requirements and design stages, require it from PD.
- When building a new service/api we start with a Walking Skeleton: Make something work end-to-end (vertical slice of the architecture, connecting the different links – api, server, db) Wrap it with CI (build automation around it) Now, add more meat Easier to develop in parallel Easier to provide deliverables faster -> Get feedback faster ~Photo: http://blog.codeclimate.com/images/posts/skeleton.gif
- Striving for large tests coverage: New code Legacy code – on changes only, sometimes using PowerMock (using custom classloaders and bytecode manipulation) No tests < Using PowerMock is better than having no tests at all < Refactoring, and mocking using dependency injection is the best!
- No tests < Using PowerMock is better than having no tests at all < Refactoring, and mocking using dependency injection is the best!
- Code Reviews Top priority is improving code quality (design, readability, standards, reuse) Correctness of the code is 2nd priority, it should be validated by tests. BUT, it’s more important to validate the correctness of the tests! Leave the code better than you found it Unlike http://blog.d3in.org/post/111338685456/maslows-pyramid-of-code-review (correct, secure, readable, elegant)
- Rules: … 2 reviewers – great communication channel Asynchronous & documented – makes it more thorough
- Autodesk TLV consists of 140 people in 3 Product teams: Spark – 3D printing platform AutoCAD 360 – CAD software A360 – Project collaboration service
- It’s the set of principals, of believes, the atmosphere that guides the team.
- You cannot force a culture. It’s usually already there, in your DNA. hacks help direct the evolution, set the tone, drive awareness
- First thing, we wanted to define our guiding star, so we stated our vision: “Building a Dream Team”. We want to be in a state where team members are proud to be a part of our team, and the rest want to join the team. And there are many culture hacks that help us get there, here are a few of them:
- It got us to Apple’s keynote
- It’s a PR for the developer/team/site/company It shares knowledge It makes the developer better
- It’s a PR for the developer/team/site/company It shares knowledge It makes the developer better
- Sponsors are the guilds initiators (one HR, and one senior member of each team in the site)
- It’s a PR for the developer/team/site/company It improves code quality It improves documentation It can scale development
- It’s a PR for the developer/team/site/company It shares knowledge It makes the developer better
- Non technical event, site-wide, 5 team members, each sharing a story about himself in 5 minutes. An amazing event that I believe contributed to the atmosphere and connections between the team members. And there are many more….
- Non technical event, site-wide, 5 team members, each sharing a story about himself in 5 minutes. An amazing event that I believe contributed to the atmosphere and connections between the team members. And there are many more….
- We’re acting on the 3 pillars: Technique: Our architecture puts the load on the client and not the server (i.e. Rendering on client side) Methodology: Using tools methodically (monthly) to review and optimize costs (Newvem, Trusted Advisor, cloudability) Culture: Encourage Ownership & Responsibility (startup culture, resources mindfulness