The conference itself
I arrived the day before the conference in Vilnius. In part because it took a some time to fly there and also because of a .NET user group which hosted a meetup at the hotel. The group used this opportunity to invite the international speaker that were already at the conference to do a presentation at their meetup.
The venue was in the Radisson Blu hotel in Vilnius. It was nice to roll out of bed, get breakfast and be able to watch the first talk. Being this late in the year the weather was not as nice and with day light savings time it was dark outside at 16:30.
Next to all the talks there were lots of booths for sponsors, competitions, food and artists who drew caricatures of you. Proof I was there:
After the second day there was an after party at a different venue. They had a DJ who created music via code, an all developer band from Lithuania and "Dylan Beattie and the line breakers"
Pictured performing their song We're going to build a Framework
Overall it was a great conference and I hope to be able to visit it in 2023 as well.
Over the 3 days I went to around 20 talks and took notes on most of them. Here are my summaries for what I think were the important ones and the ones I still have the best notes of.
Intentional code - David Whitney
Add intentionality to your code
Organizing code by architectural fucntion is a bad way to structure your project and will leave a messy structure. It is like organizing a collection of cars by the individual parts..
Design patterns were originally created by an actual building architect. Gang of Four wrote book in 1999, those patterns were used to solve problems from those times. They were templates for common encounters in code. After that came Doanlad Knnuth with Literate programming. Combining a code and documentation language.
Software is a constrained from of literature. It communicates solutions from programmer to programmer in code that is executable by a computer.
Computer code is intentional communication.
Every character that you type matters.
Code that is with thought and intention is good code.
Intentional > Clean
Extreme Programming Explained > Clean Code. Heresay!
Intent
Macro - Organizational patterns
Micro - Form, flow and cohesion
Use white space to add together code on a subject, just like a paragraph.
Complexity of an application should be atmost as complex as the problem space it inhabits and not bigger.
Not adhering to Macro and Micro design can lead to over designing
Design is temporal, only valid in current context. Example were telephones and walkmans. Design was revolutionary but now very old
Structural design is often too big and too comp;licated.
Microservices = Distributed Monoliths
Design and patterns overwhelm the problem space
Be at war with complexity.
Ask why does this code look like this and what does it do? You want things that do different things to look different
Code that you can not debug easily is bad code.
Intentionally is caring about the cost of abstraction.
file.open() is an example of good abstraction as it takes care of the difference between HDDs and SSDs.
Tip
Take more time to think about what you are doing instead of just doing it.
Actors in messaging system - Ted Neward
Talk was based on Microsoft Orleans which is a .NET framework for Actors.
How actors change up distributed systems, we want programs to talk to each other.
Ways of delivering messages in distributed systems:
- Once and only once
- At most once
- At least once
RPC → Complexity hidden behind a façade for developers. Pretend to work local as local procedure call but then in a distributed setting
RPC Flaws
- Huge traffic spike will lead to slashdot effect or reddit hug of death
- What if the network cuts out or is lagging severly? IT will throw errors
- What if we evolve the program? Did not think of that when we wrote the spec/protobuf
RPC is still request/response
Streaming services such as Netflix have to use other protocols as they can’t keep connections open forever.
Actors
Lightweight entities
Actors instead of objects
Can be stateful or stateless
Have an identifiable address
Reacts to message by:
- Sending messages to other actors
- Creating new actors
- Updating state
- Updating message format to send to others
Analogy on Actors by using speaker and audience
Actors do not share state
Message is not the same as a method call
A message may not return a response but could trigger something in another Actor.
Agility != Speed - Kevlin Henney
This talk was done without any slides as there were issues with connecting to the screens.
Agility is the way we ended up getting measured. Agile manifesto started the agile methodology.
When a company says “We are doing Agile” You know that they don’t grasp the concept.
Agile is an umbrella term not a single process you can do.
Agile is an adjective, it is an observation you can make. Team A is more agile than Team B.
You can do Scrum or Kanban but not Agile
The Agile Manifesto mentions it is not a process, it is an attitude. Agile is a continuous process.
Agile values interactions and individuals over process and tools. Agile means “Responsiveness, ready for change”.
Re-usability increases agility
No testing in Continuous Deployment = Continuous Disaster
When we measure teams we use words like “Productivity”. Productivity comes from factories. When you say “I am more productive” what you are actually saying is “I am more like a factory”.
We can easily estimate the physical world but not the abstract world of software. You can estimate when a car will arrive travelling at a certain speed, but not when that feature will arrive.
Lines of Code is a bad measurement. The only thing Lines of Code will tell you is the lines of code, it is worthless without context. It can only show what cognitive load developers have to deal with. In relation to 100k LoC vs 1 million LoC.
Developers are problem solvers and they are creative. If you measure them by LoC they will give you more code but not more value.
Story points
What is a story point?
An arbitrary unit of measure to distract us from the deadline.
“How long will this take?” We can’t answer that neutral if there is a deadline placed already.
Estimate ≠ commitment.
Estimates can be done in manufacturing. The 1001 widget will takes as long as the 1000th. In software will already fixed the manufacturing issue, it is called the compiler. If you want exactly the same thing you just need the same input.
Software is about the design problem. Software will produce different things, else you could just copy it again.
Degress of doesn’t exist
- Familiar. You have seen the technology or tried something with it.
- New technology. You have never used it before or heard of it
We don’t know how to estimate because it is a new technology for us.
Story points become currency. How much time will x take and how many story points is that? Thus x / story points = 1 story point.
When it because a currency it comes under pressure. You will end up with a conversion of story points to time. If you would then track story points over time you would say “ Team A does x amount of time in x amount of time”. Time over time becomes a gradient, you either are measuring their busyness or how good your estimates are.
Teams can have the same story points but they use a different currency. Teams can not be measured by story points alone.
Then how can we measure?
Features over time. Where feature is defined as delivered functionality.
But that is still like saying “I am having another drink. How big is the drink? I don’t know”
Another measure is velocity. Teams start comparing velocity on story points, which use different currencies. They then end up obsessing over a number.
If you put too much pressure on a number, it will fight back.
When a measure becomes a target, it ceases to be a good measure - Goedhart’s law
What about coverage(in tests)?
Coverage is not a good measure. It does not measure how good your tests are, it just measure that code is covered by a test. It does not take in consideration assertions in tests.
What is a better measure? Velocity
Velocity is not just how fast you are going
You are on your way to visit a friend an he calls you. “Where are you?” I am travelling 100km an hour. “But which direction?” North “But you need to go South!”
Velocity = A distance + a direction
1 meter per hour in the right direction is better than 100km per hour in the wrong direction.
Are we building the right thing? “No, but we are building it fast”
Agility = If we are measuring the agility of a team we are measuring their ability to change direction. To slow down the process and reassess if they are on the right path.
Fixing Distributed system fails - Jimmy Bogard
This talk was based on 6 lines of codes which each called different thrird parties without any error handling. Jimmy demonstrated what could go wrong and what you could do to counter that.
6 lines of code in a tournament order system sparked this talk.
It was code that placed an order, took customers money and send out an email.
Breakdown of code
- Find customer in DB
- When fail, transaction can rollback. Customer is not charged
- Create order from Cart
- When fail, transaction can rollback. Customer is not charged
- Post payment to Stripe
- Stripe fails, Customer is not charged and transaction rolled back
- Send email via SendGrid
- Email fails, customer never gets email but is charged. Transaction rolled back
- Create order Transaction in DB
- Queue fails, customer charged and emailed but not order because transaction rolled back
- Redirect to success page
All wrapped in a single Transaction
They are all external systems. With external system calls failure is ALWAYS an option
Not what happens IF a call fails but WHEN
You can’t wrap all calls in the transaction and hope to catch it. Plan for the worst
“Your coffee shop does not use two-phase commit”
Options for handling failures
- Ignore
- Do you want to halt your system over this fail? Logging can fail, should it stop everything? No
- Retry
- Retry the call again. But what if that one fails? Or what if the retry fails?
- Undo
- Rollback the action. Give the user a refund in Stripe case
- Coordinate
- Have a broker in place to handle both parties. Example real estate agent
For each external source pick the best option based on business requirements
Patterns
Saga pattern - Series of atomic transactions with undo and rollback. Example: Booking a vacation with hotel, flight and car rental. When vacation is cancelled each step can be cancelled as well.
Process manager pattern - Orchestration(commands) vs choreography(events). Can be a mix in a system
These patterns are mentioned in the book "Enterprise integration patterns"
Refactoring, not just clickbait - Kevlin Henney
Refactoring is not just the art of renaming things nor is it months of reengineering. Refactoring is a design practice.
Developers are drawn to complexity like moths to a flame, often with the same outcome. (from The Productive Programmer) - Neil Ford
“I can solve that problem, but I can also make it more interesting”. We(SWE’s) can always find something more complex.
Technical debt
Technical debt in itself is not a problem such as that debt is not always a problem.
If the (technical) debt is managed and structured, it has a repayment plan and period, it can be used to create things faster.
If you don’t have that in place, what you have is not technical debt but technical neglect.
Refactoring
Software development is a process of knowledge acquisition.
Later on in a project you could acquire the knowledge you needed a few weeks ago. This is when you would refactor something.
Refactoring = change made to software to make it easier to understand without changing it’s observable behaviour.
Refactoring Driven Development.
Refactor = To restructure software by applying a series of refactorings
95% of refactoring challenges have been fixed by tools, the 5% that is left is caused by the developers. Refactoring can be largely automated with IDE functions such as “Extract method”
“How we spend our days is of course how we spend our lives”- Annie Dillard
Muphry’s law → "If you write anything criticizing editing or proofreading, there will be a fault of some kind in what you have written.”
Atomic habits for developers - Natan Silinsky
Talk is based on the book Atomic Habits by James Clear
Progress = Accumulation of tiny achievements
If you went to this talk, you want to become a better developer
Achieving a goal is just momentary happiness
Avoid goals - Plan for habits
Habits follow this cycle
- Cue → Make it obvious
- What, when and where do I do the habit?
- Pair it with a context. You would learn at your desk and not in your living room.
- Crave → Make it attractive
- Habit stacking, after [habit I need], I will [habit I want]
- Response → Make it easy
- Stay below the point where it feels like work to get started
- Minimize actions you need to take to get started
- Design your environment to make it easy to do
- Reward → Make it satisfying
- Gamification
Example
Habit: Learn new tech skills
Cue: Learn during commute
Crave: Learn with a colleague, join a culture that promotes learning
Response/Easy: Listen to 1 chapter of an audiobook at a time. Do 1 coding kata.
Satisfying: Share interesting points with colleagues, start a discussion on the topic.
Breaking a bad habit
It is the reverse of creating a good habit
- Make it invisible
- Block notifications to not get distracted
- Reduce exposure
- Make it unattractive
- Negative visualization. Think about the goal you want to reach and what will happen if you stay on this bad habit
- Make it difficult
- Block apps and websites that distract you during work hours
- Use a commitment device
- Unsatisfying
- Share relapse with accountability partner
- Recap day with accountability partner
Architecting in the Cloud for sustainability - Sohan Maheshwa
Presenter works at AWS and thus the presentation was based on AWS but the principles can be used in any Cloud
How to architect in the cloud for sustainability
What you build and use in the cloud has a carbon footprint.
Sustainability drives business growth.
GHG protocol - Green house gas
Scope 1: Any fuel that is consumed at the source. A car burning oil and gas.
Scope 2: Energy used anywhere else. Example: A windmill
Scope 3: Everything else. Energy used by your consumers and suppliers.
AWS reports an 80% reduction of CO2 when moving from traditional data center to the cloud.
This differs per region, EU and Asia are 5x more efficient while USA is 3.6x times for efficient.
Shared Sustainability Responsibility
Cloud providers are responsible for the sustainability OF the Cloud
Customer is responsible for sustainability IN the cloud. Don’t run the biggest machine for the smallest workload.
Sustainability is a continuous focused effort on energy reduction.
ASDI - Free energy data on AWS sustainability.
User Behavior patterns
Example case: 2 zones with machines at 50% capability so that there is a failover capability left.
Better would be to run 3 zones at 75% so that 2 other zones could pick up slack of the failing one. This leads to better utilization of resources. First has 50% idle while second has 25% idle.
Negotiate impact friendly SLA’s. Put it in your SLA’s to use the lowest impact zones.
Software patterns
Architecting for peak usage is expensive. Better to lower the peaks and thus lowering computational needs.
Async, queues, buffers and scheduled jobs reduce peaks. However everyone runs their cronjobs at midnight, which creates a peak for the Cloud.
Hardware patterns
- Use the minimum you need
- Use managed services
- Use the correct instance type. CPU or GPU focused.
Data patterns
Think about accessing and storing data. Cold storage is cheaper and more sustainably than keeping everything in hot storage. Use lifecycle policies for this.
Use optimized data formats such as AVRO to store data instead of CSV or JSON.
Compress data whenever possible.
AWS reduced their storage by 1 Exabyte by switching to a different compression algorithm.
Development and deployment
Reduce build artifact size. This will speed up your builds and pipelines and will also lower carbon footprint.
Make sustainability part of your whole process. Report on metrics during deployments.
Eliminate idle processes
Report carbon data to leaders and customers so that they can do something with it.
Use the AWS well architected service to lower carbon footprint.