Stop punching yourself in the face!
•Download as PPTX, PDF•
0 likes•25 views
Making choices is hard. As developers, we make choices all the time: architectures, frameworks, libraries, cloud providers, etc. So, if you have been around for a while, you probably ended up regretting at least some of those choices. In this talk, you will learn how to make choices responsibly and what to look out for if you want to minimize the chance of regretting them later. I dive into several situations where the choices we made as a team have gone horribly wrong. Luckily, I learned these lessons the hard way, so you don’t have to! Now, if only there was a way to prove your newly acquired skills to your peers and superiors. Well, there is: RAD Certification! I will conclude my talk by telling you about this. And as a bonus, if you get certified during the conference, you can score your RAD certificate and corresponding swag!
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Stop punching yourself in the face!
Similar to Stop punching yourself in the face! (20)
Recently uploaded
Recently uploaded (9)
Stop punching yourself in the face!
- 1. Stop punching yourself in the face! Hannes Lowette
- 2. We need to talk …
- 3. What we do
- 4. The magpie • Bird (black & white) • Long tail • Up to ~45cm long • Wingspan up to ~60cm • Omnivores • Intelligent (Rumoured to be…) • Attracted to shiny things
- 5. The software developer • Human being (black/white/…) • No tail • Up to ~220cm tall • No wings • Omnivores • Intelligent (libraries, frameworks, architectures, …) • Attracted to shiny things
- 6. Technology evolves We chose this profession regardless … Is this surprising? No recipe for success
- 7. Our education … Can you design and build a house?
- 8. We look for guidance And we do as they do …
- 9. … until we run into a wall!
- 10. But why do we run into that wall?
- 11. Join me for an adventure with CHAD* … * Any resemblance to actual persons, living or dead, or actual events is purely coincidental.
- 13. The case
- 14. CHAD’s solution
- 15. What went wrong? RavenDB • € Per GB: pretty high • Maintain the OS • Maintain the DB engine The solution • Took longer to write • Breaks on file structure changes
- 16. What did CHAD forget? Technical fit Is this technology suitable to solve my problem?
- 17. Technical fit Ask yourself questions such as: • Does this help with our problem? • How does it compare against competitors? • Is there something that will help us more? • Is this the simplest thing we can do? • Does it bring unnecessary costs? • Is there extra maintenance?
- 18. Why did CHAD go wrong? RavenDB is a database If you only use it for storage, it is expensive
- 19. What could CHAD have done? Azure BLOB storage: • Easy to set up • No parsing required • € per GB: very cheap • Very robust (and easy to distribute) • No maintenance needed
- 21. The case
- 22. CHAD’s solution Agatha RRSL • CHAD had experience with it • Agatha in MVC • Solved our issue • In process (no overhead) • But could move to ‘over WCF’ Technical fit was OK
- 23. What went wrong? Agatha: • Mainly maintained by 1 person • Maintenance stopped in 2013 Agatha had become a liability
- 24. What did CHAD forget? Check for warning signs Can this technology become a risk?
- 25. Warning signs Ask yourself questions such as: • Who maintains this library? • Are they still actively working on it? • Is the source available? • What licensing model does it use? • Has the product recently been acquired by another party?
- 26. What could CHAD have done? MediatR: • Similar functionality • Open source, Apache license • Actively maintained (by multiple people)
- 28. The case
- 29. CHAD’s solution EventStore Technical fit was OK No warning signs
- 30. What went wrong? The team: • Juniors • Remote contractors • No EventStore knowledge The team never touched the EventStore stuff CHAD was the only one who worked on that
- 31. What did CHAD forget? Team skills Can we get everyone up to speed on this?
- 32. Team skills Ask yourself questions such as: • Do we have the knowledge? • If not, is the knowledge available? • Can we teach the team? • Can everyone work on it? • What documentation do we need?
- 33. What could CHAD have done? Spread the knowledge: • Teach the team • Write code together • Write documentation • Help others take their first steps
- 35. What happened “We need to stop using Entity Framework”
- 36. EF frustrations • Very slow • Does too many things • No control over SQL • The SQL is very messy True, but …
- 37. What went wrong? We used: • SQL server profiler • Query plan analyzer We saw: • DbContext initialization • N+1 select • Missing DB index • Too many fields fetched
- 38. Until that day Entity Framework was magic to CHAD
- 39. What did CHAD forget? Take away the magic Do you understand how it was built?
- 40. Take away the magic Ask yourself questions such as: • Do we know how it works? • Do we understand how it was built? • What did the developers use? • What concepts are applied? • Could we (theoretically) build our own? • Do we know the effect of our usage?
- 42. The case
- 43. Their approach • When CHAD learned • A better way • A new framework • An awesome library • He explained it to the team: • Presentation • Pitfalls • Tips & tricks From then on, they would do it like that!
- 44. What went wrong? Old code stayed ‘the old way’
- 45. What did CHAD forget? Trim your stack When new tech goes in, old stuff must go out!
- 46. Trim your stack Ask yourself questions such as: • What problem does this new tech solve? • Do we really need that? • Which old, similar, thing do we have? • Can that be replaced by the new one? • How much effort would that be? • What effect does it have to keep booth? • On maintenance • On onboarding
- 47. What could CHAD have done? “Hollow out the trunk”
- 49. The case
- 50. The solution • Angular • IdentityServer • Docker & Kubernetes • Microservices • MongoDB All of this was new to them
- 51. What went wrong? The team got stuck on: • Learning the new stack • Deployments • Debugging • MongoDB The project got a huge delay Massive ‘team skills’ violation Over-engineered
- 52. Team skills - revisited New skills in real projects: • Don’t combine learning & delivery goals • Budget extra time • 1 at a time • Explain the risk to the business “This new way of doing things will make sure we can deliver more, with higher quality.”
- 53. What else did CHAD forget? Evolving architecture Architecture follows your problems, not the other way around!
- 54. Evolving architecture KISS • Start with the simplest solution • Discover your needs from PROD • Adapt to those needs, extract services You’ll have a working product WAY faster
- 55. Microservices? When? • Scale independently Balance cost with speed • Multiple clients Clients can adopt features at will • Different technology stacks • Conflicting dependencies
- 56. What could CHAD have done? Let the architecture follow the needs Start simple: • ASP.NET & Angular (1 new thing) • No microservices Structure code to allow decoupling: • SOLID • Vertical slices Deliver your value!
- 57. Summary 1. Technical fit 2. Check for warning signs 3. Team skill 4. Take away the magic 5. Trim your stack 6. Evolving architecture
- 58. No really, who is CHAD? • Me • The whole team • Someone else • Totally made up He acted because he cared! Carelessly or Helplessly Acting Developer
- 59. Wouldn’t it be better to be a … RAD? Responsibly Acting Developer
- 60. Are you on board with this mission? 1. Spread the word! 2. Follow us on Twitter: @RadCert 3. Take the quiz at https://rad-cert.com 4. Come find me later to pick up your SWAG
- 61. Hannes Lowette • Head of Learning & Development • Competence Coach .NET • Father of 3 • Amateur guitar builder • LEGO® enthusiast @hannes_lowette #20086521
- 62. Questions?
Editor's Notes
- My talk today is about: A personal pet peeve Something that is annoying me more and more And the problem IS NOT getting smaller
- As software developers, we are paid to do one thing: DELIVER VALUE Sounds pretty simple, right?
- Let me tell you about the magpie … Bird (black & white) Long tail Up to ~45cm long Wingspan up to ~60cm Omnivores Intelligent (Rumoured to be…) Attracted to shiny things
- And then there’s us, the software developers … Human being (black/white/…) No tail Up to ~220cm tall No wings Omnivores Intelligent (libraries, frameworks, architectures, …) Attracted to shiny things
- In the software world: Technology constantly evolves New things are invented daily Unlike, for instance carpentry, our profession is still young: We are still finding better ways to do things There is no recipe for success Education is limited BUT … We chose this profession regardless, which means: we like change we like new challenges
- If you teach someone to: Lay bricks Do tiling Construct roof timber Do an electrical wiring diagram Connect pipes for plumbing Can they design and build a house? Yet, this is what we expect software developers to do!
- If you teach someone to: Conferences (like this one) Blog posts, articles, books, the internet The big guys: StackOverflow Facebook Google … The most dedicated developer in our team And we do what they do…
- I’m sure you’ve felt like this as a software developer
- Who is CHAD*? A developer Ran into that wall We will learn from his mistakes!
- We were building a solution to process text files: Used about 70% of the data The other 30% might be useful in the future Task: Store them somewhere for future use
- We were building a solution to process text files: Set up RavenDB on a new VM Parse the contents of the text files Upload to RavenDB
- We were building a solution to process text files: Used about 70% of the data The other 30% might be useful in the future Task: Store them somewhere for future use
- RavenDB is a database: Meant to be queried With indexes, projections, etc. Optimization for query = concessions for inserts We were not using most of RavenDB. If you only use it for storage, it is expensive BOTH in operations cost and practicality
- It was 2014 (this is important!) ASP.NET MVC Project No separation between UI/Logic/Data Issues due to N+1 selects from the views Inexperienced remote developers Task: Make sure EF & logic are shielded
- Agatha = Request/Response Layer CHAD had used Agatha before Doing Agatha from MVC Controllers Solved our problem technically Didn’t introduce real overhead Made us think about Includes etc. Ran in process, but could move to ‘over WCF’ Technical fit was OK
- Agatha: Mainly maintained by 1 person Maintenance stopped in 2013 No async/await support Dependencies didn’t get updated PRs didn’t get approved Agatha had become a liability, not an asset
- Who maintains this library? Are there multiple maintainers? Are they still actively working on it? Commits Blog posts Is the source available? readable and well structured? Can we legally use it? What does the licensing model look like? How likely is that model to change? Has the product recently been acquired by another party?
- MediatR: Almost the same functionality Source on GitHub Apache license Jimmy Bogard still blogs about it Actively maintained (by multiple people) This seems like a safe bet!
- ASP.NET MVC Project Decent SOLID Some messaging to other products Task: Build a screen with: an audit trail Resulting state
- CHAD had recently become a fan of Greg Young & CQRS CHAD decided on using EventStore Wrapper around the actual EventStore stuff For other devs to easily do the same Implemented the screen using his wrapper Technical fit was OK No warning signs
- Team: Lots of juniors Some remote contractors (abroad) No prior EventStore experience The wrapper: Meant to solve this knowledge gap Only worked for a pretty specific case No access to the wrapper’s source The team never touched any EventStore screens. CHAD was the only one who worked on those.
- Do we have the knowledge? What it does How it is meant to be used What are the pitfalls? If not, is the knowledge available? Documentation Tutorials Book Code samples Can we teach the team? Give a presentation Build a POC together (hackathon?) Does everyone have the background to understand? Can everyone work on it? For the implementation For maintenance What documentation do we need?
- Spread the knowledge: Research the pitfalls and best practices Give a presentation to the team Organize a hackathon to try it out together Pair with another dev (preferably a junior) for the implementation Document the wrapper: Usage Effects Inner workings Make his wrapper code public Assist the team when they first touch that code
- CHAD took me aside to talk to me: We should stop using Entity Framework We should write our own SQL instead We could use a micro-ORM like Dapper (his latest library-crush) Context: Our application was mainly CRUD Not a lot of high-load code either
- The reasons he gave me were: EF is very slow EF does too many things We have no control over the SQL it outputs The SQL is very messy All of these have truth to them, in the right context
- We looked at some problematic code: Used SQL Profiler Analyzed query plans We saw: DbContext initialization delays just started in Debug mode An N+1 select Include to fix A missing index in the DB Query was OK A crazy amount of fields were fetched projection FTW
- Entity Framework was MAGIC to CHAD He didn’t know how A LINQ statement becomes a query How Lazy Loading actually worked What ModelCreating does Etc. It was a black box that took away the need to understand/write SQL After that, he became a FAN
- Ask yourself questions such as: Do we know how it works? Do we understand how it was built? What did the developers use? What concepts & technologies are applied? Could we (theoretically) build our own? Do we know what the effect of our usage is? How? Look at the source code Use a profiler Try to build a simple version yourself
- Long running project (8+ years) CHAD was the lead developer The whole team admired his skill The only one who learned in his free time Liked ‘doing things right’ Took care of the ‘team skills’ part really well
- Never re-wrote the old code: Business didn’t want to invest in old features The team was already under pressure So old code stayed ‘the old way’ The result: 4 ways of writing frontend 3 ways of doing backend 2 API frameworks 2 database engines 3 ways of structuring backend code … Training a new developer in this codebase was impossible You could tell by the utilized features when the code was written
- “Hollow out the trunk”: Replace old tech as new tech arrives Add the estimate of the removal to the ‘cost’ of the introduction Make the pain of this technical debt visible Limit introductions when previous transitions aren’t complete
- Small LOB application Little complexity Greenfield Team: Experience in ASP.NET MVC 1 senior 3 devs < 3y experience No real ops experience
- Never re-wrote the old code: Business didn’t want to invest in old features The team was already under pressure So old code stayed ‘the old way’ The result: 4 ways of writing frontend 3 ways of doing backend 2 API frameworks 2 database engines 3 ways of structuring backend code … Training a new developer in this codebase was impossible You could tell by the utilized features when the code was written