Think About What You Do!
When The Hammer Becomes More Important Than Driving Nails
01 week ago
by Alexandru Bolboaca
in Articles
Back in the 1980s a few developers realized that common patterns appear in the code everybody was writing. They documented them in 1995 a famous book called “Design Patterns: Elements of Reusable Object-Oriented Software”. Today, many software teams have a guideline stating they must use design patterns.
In early 1990s, one former US AirForce pilot became Chief Engineer of a software company. The teams he was working with had many troubles while developing a product. Trying to fix the issues, he decided to fundamentally change their workflow. In 1995 he introduced his new method to the world under the name of Scrum. Today, software teams adopting it often focus on one thing: how to do Scrum by the book.
I can only imagine how the world would have evolved if we treated hammers in the same way. Someone needed to bind two pieces of wood together, thought of nails and used a piece of metal to drive them. He shows his method to other people, they all use it and they call it “hammer”. The 3rd annual convention on the topic focuses on making hammers too light to drive nails anymore.
It doesn’t mean that design patterns are bad, Scrum is useless and hammers aren’t helpful. Just that we tend to forget the purpose and focus on the method.
5 Whys Shouldn’t Be 5 And Shouldn’t Be Whys
02 weeks ago
by Alexandru Bolboaca
in Articles
Romanians have a class of jokes called “Radio Yerevan” jokes. My favourite one is:
Is it true that Ivan Ivanovich Ivanov from Moscow won a car in a lottery?
A: In principle yes, but:
- it wasn’t Ivan Ivanovich Ivanov but Aleksander Aleksandrovich Aleksandrov;
- he is not from Moscow but from Odessa;
- it was not a car but a bicycle;
- he didn’t win it, but it was stolen from him.
I realized that the same happens with the rule of 5 whys.
This rule states that to find the root cause of an issue in a team you have to ask five times “Why?”. This technique is part of lean methods and was initially used as part of the Toyota manufacturing system. It was then adopted as a tool for agile coaching.
This rule is however a lot like a Radio Yerevan joke. It is very useful but:
- You shouldn’t ask why because it’s annoying and puts some people in a defensive stance
- You shouldn’t ask 5 questions because it might be too much or not enough
My rule is that I ask context-free questions until I am satisfied I understand the problem.
The best resource I could find for context-free questions is the CIA “Phoenix” checklist. I recommend this list to everyone who needs to find solutions to a problem. It’s amazing how it makes people move around a problem and understand what they are missing. Some of my favourite questions from the list are:
- Why is it necessary to solve the problem?
- What isn’t the problem?
- How many different ways have you tried to solve the problem?
- How will you know when you are successful?
The second part of the rule is more subjective and requires experience. JB Rainsberger taught me another, easier to adopt way:
Ask questions until your interlocutor starts thinking
So here it is, use the 5 whys rule but don’t ask why and don’t ask it 5 times. Everything else should be fine.
The case for tinkering
03 weeks ago
by Alexandru Bolboaca
in My take on
When I was a boy the most common car in Romania was Dacia. Compared with modern cars, it is awful. It looks quite bad, you need a lot of force to steer it, putting it into reverse gear is a mix of force and accuracy and you are lucky if it starts when it’s cold outside. 
It requires a lot of maintenance or it will stop working. The bodywork erodes in a few years and it needs special treatments to stop it from falling apart. Its performance is low too; often when it got to 100 km/h it starts trembling like a rocket just launched to the outer space.
(more…)
10 Reasons to Attend a Code Retreat
02 months ago
by Alexandru Bolboaca
in Articles
You will love programming again
You relive the first moments of programming (unless you started with Cobol)
You will see how other people write code
You will write and speak about code all day long. You’re between friends, accept that’s the one thing you could do for days
You come as an expert and leave like a novice
To live a paradox: it couldn’t possibly work but it does
You experience 3-4 programming languages you never tried before
There’s beer after it
You could use it to find a new job
Pair programming, TDD, clean code, refactoring
10 bis. For Romanians: Romania was the second country in the world to host one
Yes, I’m a sinner
03 months ago
by Alexandru Bolboaca
in Articles
I am sure that by now you have heard about Steve Jobs and his premature death. Here’s something you probably haven’t heard about.
Dennis Ritchie died this week. You probably never heard of him. I never heard of him until today, showing once again that I’m guilty of the developer sin #3. And the sad thing about it is that Steve Jobs might not have become the person we know if it weren’t for Dennis Ritchie.
How come? Wikipedia sheds some light:
Dennis MacAlistair Ritchie (September 9, 1941 – October 8, 2011), commonly known by his username dmr, was an American computer scientist notable for developing C and for having influence on other programming languages, as well as operating systems such as Multics and UNIX.
MacOS and Linux derive from Unix. They are mostly written in C. Either of those might not exist if it weren’t for Dennis Ritchie.
I can understand why the public wouldn’t know the names of great software engineers. I don’t understand how we, software developers, allow ourselves to not know their names, lives and principles. I don’t understand how we allow ourselves to forget history and why we have no heroes.
There’s still a hope: maybe I‘m the only one who didn’t know him. Maybe I need to learn history. Maybe I need heroes.
Somehow, I doubt it.
UNIX is very simple, it just needs a genius to understand its simplicity.
C is quirky, flawed, and an enormous success
– Dennis Ritchie
