CAP Theorem@Codemotion 2016, Milan

I just come back from Codemotion Milan, and it was great! Apparently a lot of people liked my presentation, someone told me that they really understood, for the first time, the CAP theorem. Which is absolutely great!

Thanks for everybody who attended, you were a fantastic bunch and I feel absolutely grateful and privileged for being there!

I am looking forward to the next tech meeting or conference!

Ah, the code is on GitHub but please keep in mind that this is basically the result of a four days spike, so it’s not particularly good. But I promise I will refactor it 🙂


My PM wants to take a shortcut. How do I explain my engineering point of view?

In this post we describe a situation between me, the head of engineering, and a PM (Don)  that wants to push a (not very good) solution to one of the engineering team. The engineers are pushing back, and Don does not understand why. Everybody is in good faith, but they do not understand each other…

Dear Don….

Let me try to explain the issue here from my point of view. This is a classic problem in software engineering, and it happens all the time: however, if you want to understand it you will have to take a bit of time, at least as much I invested to write this, so please sit down, relax, and enjoy the ride!

abstraction consists in capturing those portions of reality that are significant for your problem

One of the core concepts of software engineering is abstraction, which consists in capturing those portions of reality that are significant for your problem: software systems tries to represent reality, but its complexity can be overwhelming. Imagine that you want to model a car: how would you do that? Would you represent it with four wheels, four doors, a bonnet? Or would you consider its speed on the road, its position on the territory? What about the current angle of the steering wheel? The number of revs of the engine? I could go on forever. The fact is that you have to capture a portion of it, the parts that make sense for your problem. So, if you plan to manage a factory that build cars, then the structural abstraction (wheels, bonnet, doors) is a good one, while if you are building a navigation system you will be mostly interested in its position, speed and similar.

models are implementations of abstraction in the software realm

Once you have defined the overall abstraction that you want to use, then you end up defining your models, which basically are implementations of the abstraction in the software realm, defining structure and behavior based on our requirements. In an Object Oriented approach those are usually represented (unsurprisingly) by objects, which may have (on some typed languages) also a generalization, which is basically a blueprint to create objects (usually called “class”, but that’s not really important). They may also have some form of persistent representation, which can be stored in a relational database (like MySql) in the form of records on tables, or  as a document on a nosql database (like Mongo). They also have a tight relation to the user experience, which should be built around such models and should match the mental model that we (and our users) will instinctively adopt and use.

on every change the models must be improved to accommodate future changes

I hope it’s clear now why models are so important, and how pervasive they are: basically they are the foundation of our software, get them wrong or screw them, and you will have very big problems. For that reason maintaining and evolving these models correctly is extremely important, and the trick is to make sure that at every change we make, the models are improved so that’s easier to accommodate changes in the future.

your change does not evolve the model, it violates the underlying abstraction, and makes it harder to change

Now, the change that you are suggesting consists in picking a portion of that model and changing it violating the underlying abstraction: you are basically proposing to screw it. You are not evolving it, you are not making it  easier to change in the future, you are just patching it. And when you continuously make changes like these then you end up with a pile of crap that you won’t be able to change at all. Sounds familiar?

do not offer solutions, state the problem

For that reason the engineers are resisting this action. So, do not offer solutions: state the problem, and trust your team to come back to the right solution! And if it’s not right.. well, failure should be part of the process. Like Lynda Resnick once said, “you will learn more from your failures than your successes“.

You shoud attend a conference. No, better, be a speaker!

I just come back from Codemotion Amsterdam and it’s been a fantastic experience! I met a lot of smart guys, I’ve been infected with a lot of new ideas, and I honestly cannot wait to come back to work to share this fun! It’s incredible the amount of knowledge you can pack in two days, the inspiration that you can get, if only you try!

But I was also a speaker there, and I thoroughly enjoyed the fact I was able, myself, to influence people. And a very good breed of people, the ones who actually go to a conference! Some of them took some days off to attend, gave up a couple of days on the beach in the sun to attend a conference and, among other, see me 🙂 How cool is that? These are the people you want to have, as engineers, in your company! People who actually care, who are willing to do sacrifices to learn and to improve themselves!

How many of them do you have in your company? You should do something about that, you should try to get the best people around, and make sure they stick with you big time! So, now, go, check, NOW! How many people do you have in your company that have this (brave, sane and good) attitude?

And what about speakers? That’s the next step! How many people, in your company, decided to be a speaker at a conference? And to risk public humiliation, the fear of the demo going wrong, the nights spent preparing slides, the endless rehearsals… for what? Speakers usually do not get paid. Sometimes they get refunded some costs, sometimes not. And yet… they do it! Because… because we can! I remember my first European conference, Javapolis 2006 (now known as Devoxx) where I talked about Selenium and FitNesse… I was scared, I was unsure, I felt very unsafe, but I did it, and it went well! And if somebody like me, at the time, did it, YOU can do it! Start small, an internal meeting, then meetup or a local user group, then a small national conference, then a bigger one, then a European one… YOU CAN! And it’s awesome!

Now, I am an old fart, and even if I’ve been speaking at many conferences during my career  I am almost out of the game (hey, I said almost!) and the best thing I can do is to breed the new generations to come 🙂 And heck, I will make a point, I will make sure my developers will be speakers, so that this beautiful cycle will continue.

I will have speakers in my company, promise!






No comment

“…we recognize that proactive notification of planned maintenance is a much-requested feature, particularly to help prepare in a situation where you have a workload that is running on a single VM and is not configured for high availability. While this type of proactive notification of planned maintenance is not currently provided, we encourage you to provide comments on this topic so we can take the feedback to the product teams.”

That’s still how it rolls in 2015+

Ubuntu: disable indexing

If you are a developer the last thing you want running on your system is an indexing daemon, that keeps the cpu busy and eats precious i/o. If you’re like me, you want to get rid of it as soon as you can! Yes, we all know that the thing is “configurable”, but anyway it keeps eating resources and it will also slow down your desktop (if you have one)
So, just go to synaptic (or apt. if you are a command line guy) and remove “tracker” and related dependencies. Be sure to remove also “beagle”, you may have installed in some previous life 🙂

There Will Be Code

“Remember that code is really the language in which we ultimately express the requirements. We may create languages that are closer to the requirements. We may create tools that help us parse and assemble those requirements into formal structures. But we will never eliminate necessary precision — so there will always be code.”

Robert C. Martin – Clean Code