Feed #113


Agile and Leadership – Turn the Ship Around

Towards an Agile Software Architecture


Back to 28: Grub2 Authentication 0-Day

Oracle ordered to admit on its website that it lost the plot on Java security

Security Panel debuts in Chrome DevTools | Web Updates - Google Developers

Web dev

DevTools Digest (CDS Edition): A glimpse into the future + RAIL Profiling | Web Updates - Google Developers

How to Write Unfancy Web Apps

HTML5 Video is now supported in Firefox - The Netflix Tech Blog

The Website Obesity Crisis

Code style

To String or to string

When coding style survives compilation: De-anonymizing programmers from executable binaries


The Famous ‘Social Experiment’: 5 Monkeys and a Ladder

What You Believe Affects What You Achieve - Bill Gates


What is Microservices Architecture?

Microservices and Teams at Amazon

The Seven Deadly Sins of Microservices

How we ended up with microservices - ex-SoundCloud dev
This article is a goldmine about team work, software architecture, code ownership and culture:

“that very frequently your feature would be rolled back because of a problem in a completely unrelated part of the code.”

“Most people were happy with pairing, and those who weren’t happy were given the option to keep working by themselves, but only on tasks not related to the Next project.”

“Turns out that the monolithic code base we had was so massive and so broad no one knew all of it. People had developed their own areas of expertise and custodianship around submodules of the application.”

“A meme around the company was “everything is fun and games until someone has to touch the monolith”.”

“The irreducible complexity of the monolith”

“But even if everything went smoothly, we knew that the current code for the monolith had to be refactored anyway. The code had suffered a lot during the past few years, tech debt everywhere.”

“Anything new we were to build would become a greenfield project, and the delay introduced by Pull Requests wouldn’t be necessary.”
“We decided to give it a try, and eventually built everything required for our first monetisation project as services, isolated from the monolith. The project introduced several big features and a complete revamp of our subscription model, and it was delivered ahead of deadlines by 2 teams of 2 engineers each.”

“People would still either implement the change in the old code base or create some weird hybrid, where the changes would be implemented in a microservice that was so coupled to the monolith that it might as well be the same system.”

“People would be jumping from one feature to another all the time, and we realised that we didn’t develop a sense of ownership or autonomy towards any part of the system. Nobody wanted to make the risky investment of extracting some ancient piece of code if they didn’t feel responsible for it. It’s an instance of the old adage: what’s everybody’s responsibility is nobody’s responsibility.”

“We could finally afford having these people facing the extraction of modules from the monolith as a project in itself.”