Since it’s introduction over 20 years ago, Java developers have had plenty of strong and often opposing ways of doing things.
Modern day JVM development has only added more options, more divisiveness, and even more heated arguments.
* Constructor or Setter Injection ?
* Dynamic or Static typing ?
* Monolithic or Micro-service application design ?
* Java or Scala or Kotlin ?
* JVM or .NET ?
* Reactive ?
* Are Mutable types and Threads inherently Evil?
* Is Kubernetes / Docker the modern way of JVM deployments?
Let’s dive into these and other issues .. while also stepping back and looking at the Bigger Picture:
What is it really about these choices that improve the bottom line ?
Most importantly .. let’s also settle once and for all:
Maven or Gradle?
3. FLAME WAR STEPS
▸ The Talking Parrot Phase
▸ “It’s got Electrolytes” , “It’s Web-Scale”
▸ The Google Lookup Phase
▸ “X is better then Y”
▸ The Emotional Breakdown Phase
▸ “X sucks! , Y is evil!” , name calling …
▸ .. if you’re lucky “Goodwin’s Law”
5. LEVEL SET
▸ Economics 101
▸ Needs are infinite, resources are finite
▸ Probability 101
▸ Rule-of-Thumb, “In general,” , sensible defaults
▸ Human Nature 101
▸ Self-Interest / Identity
▸ Biases / Shiny-Objects
▸ Rules based -> Big Picture (Dreyfus Model)
6. DREYFUS MODEL OF SKILL ACQUISITION
Novice Begineer Competent Proficient Expert
Rigid Adherence to Rules
Holistic Picture
7. DEVELOPER PRODUCTIVITY
▸ Higher-Level Trend
▸ Key velocity driver
▸ Getting closer to “business value” / “English”
▸ Majority of time and cost is in Maintenance + Day 2
▸ Cost directly proportional to number of moving pieces /
LOC
▸ Average developer job length - ~2 years
8. DEVELOPER WASTE
▸ Eliminate Waste
▸ Time spent on non-value add items, is NOT spent on actual
business value
▸ Everything is a Trade-Off
▸ Hardware Costs (↓) vs Human Costs (↑)
▸ Flexibility is a Cost ! Change is Certain
▸ Reduce Cycle Time , MVP, YAGNI
9. DEVELOPER DECISIONS
▸ Leverage Industry Lessons
▸ What are Startups doing ?
▸ What are the Giants doing?**
▸ Proven tech instead of DIY
▸ Market Trends / Hiring
▸ StackOverflow / Google Trends
▸ Transparency around the Cons / Costs
▸ Include Alternatives!
** Keep in mind you’re NOT operating NetFlix scale!!
10. CONSTRUCTOR DEPENDENCY INJECTION
▸ Alternatives:
▸ Setter or Field
▸ @Required annotation
▸ More Readable ? Better for Testing?
▸ Less Error-Prone ?
▸ Just Stay Consistent !
▸ Stop Bike Shedding !!
13. SCALA
▸ More succinct then Java, focus on performance
▸ Steep Learning Curve / High Investment
▸ Non-Standard Stack (SBT, Akka, Actors, Play, etc)
▸ IDE Support / Backwards Compatibility Issues
▸ Questionable MarketTrend
▸ Questionable Performance
▸ Justify with real Metrics
14.
15. KOTLIN
▸ More succinct then Java, focus on developer productivity
▸ True Null-Safety (not Optional!)
▸ Low Learning Curve / Low Investment
▸ Works well with Java EcoSystem
▸ Great IDE Support! Backwards Compatibility !
▸ Positive Developer Productivity Improvements
▸ Positive MarketTrend
▸ Question of Political Capital .. (Esperanto)
16. DYNAMIC TYPING
▸ Less Code
▸ Not being forced to define full contract (JSON, XML, REST, DB, etc)
▸ SOAP (WSDL) -> REST -> Spring Cloud Contracts
▸ Checked vs Runtime Exceptions
▸ More Error-Prone
▸ Testing was suppose to negate this
▸ Alternatives exist:
▸ XPath, Optional Typing, etc
▸ Upfront Velocity Improvement , Long Term Maintenance Costs
▸ Minimize for Corporate
17. .NET (C#)
▸ More succinct code (historically)
▸ Lacking ecosystem (historically)
▸ Windows, IIS, Visual Studio, NuGet, OSS Support, Costs!
▸ Still Lagging with Cloud-Native
▸ Would a startup use .NET?
▸ StackOverflow aside!
▸ CEO Friday: Why we don’t hire .NET programmers
▸ Dependant on current developers / code / and market
18. PAIR PROGRAMMING
▸ Costs:
▸ Developers don’t type twice as fast with someone sitting beside them
▸ Design by Consensus
▸ Mitigates:
▸ Ivory Towers
▸ Knowledge Silos / Information Hoarding
▸ The Elephant in the Room :
▸ Highly Focused Development / Minimized Distractions
▸ Healthy Competition
▸ Give it a try !!
▸ Mandate helps
19. AUTOMATED TESTS
▸ Granular mock heavy Unit Tests, and BDD style (Cucumber Tests)
▸ Costs (often ignored!)
▸ Refactoring Costs / Avoidance
▸ Testing Plumbing instead of Business Value
▸ Additional Layers (BBD Cucumber)
▸ Alternatives Exist:
▸ Smoke Tests / Integration Tests
▸ Monitoring / Alerting
▸ What about TDD?
▸ Focus on ROI + delete Questionable Tests
20.
21.
22. COMMON CODE BASES
▸ Internal Frameworks, ORM’s, Platforms, Testing Libs, Common-Libs, etc
▸ Costs:
▸ Learning Curves for Developers
▸ Dependency on Current developers
▸ Not writing actual business value!
▸ Maintenance Costs
▸ Multiple Repos / Artifactory / CI requirements complexities
▸ Alternatives:
▸ Embed in Application (first 3 times)
▸ Use 3rd Party (often OSS) solutions, which will almost always be better documented / supported
23. GRADLE
▸ Benefits:
▸ Easier to Read (no XML), Less LOC
▸ Easier to Extend (instead of Bash scripts!)
▸ Significant Build Time Improvements! (X factor)
▸ Comes down to Political Capital
24. MULTIPLE SOURCE CODE REPOSITORIES
▸ For Same Team and Same Deliverable
▸ Costs:
▸ Lack of Atomicity between commits
▸ CI/CD overhead
▸ Local Development costs
▸ Would would Jesus Google do ?
25. MICROSERVICES
▸ Tackles challenges of Monoliths (especially large size ones)
▸ Costs (almost always ignored!)
▸ Performance, DevOps, Transactions, Versioning, Resource Costs, etc
▸ “You must be this tall to use”
▸ Alternatives Exist:
▸ Cookie Cutter Scaling (Easier Scaling!!)
▸ “Decouple” at Project Level
▸ Address fundamental issues first !
▸ Monoliths are not EVIL! - Can scale and cleanly separate / decouple code !
▸ Default to Pizza-Team Sized Services - “Right-Sized Services”
26. KUBERNETES (CAAS)
▸ Comparing to IaaS or PaaS?
▸ Higher Level of Abstraction then IaaS
▸ Orchestration, OS Abstraction, Availability
▸ Lower Level of Abstraction then PaaS
▸ Networking, Buildpacks, Pods, Docker Files, etc
▸ Stick to the Highest Possible Level of Abstraction
27. REACTIVE PROGRAMMING (WEBFLUX)
▸ “Non-blocking” stack to minimize thread usage and scale better (i.e. Performance Optimization)
▸ Costs
▸ Steep Learning Curve / Legibility / Testing
▸ Concurrency Performance Gains
▸ High Count (1000+) (↑) , Low Count (↓ ?)
▸ Limited Support (Database / FrontEnd)
▸ Positive MarketTrend
▸ Threads are NOT bad !!
▸ Consider the Trade-offs / you can mix and match (with Spring-MVC)
32. OTHER ITEMS OF CONTROVERSY
▸ Tabs vs Spaces
▸ EJBS’s
▸ IntelliJ vs Eclipse vs NetBeans
▸ Optionals
▸ Server Side vs Client Side (SPA)
▸ ReactJS vs Angular
▸ 10x Developers
▸ OOP vs Functional vs Procedural
▸ Branching
▸ CPU / Thread Optimization
▸ Immutable Types + “final” on everything
▸ Theory of Constraints
▸ …
33. KEY POINTS
▸ Think Big Picture + Context
▸ .. instead of Tech X Sucks / is Bad / etc
▸ Rules are great for beginners (pick the right ones!)
▸ Focus on ROI
▸ Trade-offs / Opportunity Costs
▸ Fundamentals
▸ Maintenance Costs (minimize Snowflakes)
▸ Metrics (instead of assumptions) to drive non-standard choices
▸ What’s your Developer “Identity”?
▸ Technologies come and go!
▸ Default to Simplicity instead of Rube-Goldberg Machines