Think About What You Do!
Alexandru Bolboaca
(4 comments, 36 posts)
Yahoo Messenger: alex_boly
Jabber/GTalk: alexboly@gmail.com
Posts by Alexandru Bolboaca
Refactoring Keeps Functionality Intact
03 months ago
The development team gathers to find a solution to cut technical debt.
“We cannot finish this feature in time. We need to change too much code to do it”. Joe, the technical lead, was always direct and honest.
“What would help?” Bill, the manager, was not happy, but he trusts Joe. If he told him that’s a big problem, he’s certainly right.
“We need to refactor parts of the code”
“How long would that take?”
“I guess about two weeks.”
“Fine, let’s do it” Bill is still not happy, but what else can he do?
I’m sure you have seen this story happening again and again. Usually the team asks for a “refactoring sprint” or “refactoring period” to “cut some of the technical debt”. The manager and the customer has to choose to invest in refactoring or risk schedule variance.
What’s wrong with this story? The developers clearly have good intentions and the managers make the call. But is this the only choice?
When The Hammer Becomes More Important Than Driving Nails
04 months 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
04 months 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
14 months 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
05 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
