Think About What You Do!
A Programmer Story
02 months ago
by Alexandru Bolboaca
in Articles
Last couple of weeks, a few things happened that made me think. First, I started building a prototype for a Java application in Grails using Eclipse. Second, I wrote some small tools for Mozaic Works in python using Eclipse or vim. Third, I am involved in a startup that uses PHP to develop a great game. Fourth, I had my first TDD in C++ workshop in Stockholm. And, not to forget, my laptop runs Ubuntu.
I compared my last weeks with who I was 7 years ago. For my entire developer live, I used Windows and Visual Studio. I switched from C++ to C# in the 2000s, because it was new and better for the kind of applications I was doing back then. I knew a lot of things about Linux. I played with some scripting languages and was starting to like them. But why bother more? (more…)
I love Legacy Code!
16 months ago
This is how I started my Wildcard Talk at XP Days Hamburg 2012. It was really fun doing the kata on legacy code techniques in front of a great audience, and many asked me if I wrote about these techniques somewhere. Well, I just had! (If you just want to see the video, scroll down, I just added it).
So, let’s start with the basics. What is legacy code?
How to Change An Organization
06 months ago
by Alexandru Bolboaca
in My take on
I’ve recently commented on a conversation in the Agile Coaching group on LinkedIn. I’m reproducing my comment here because it relates with a misconception that I see often.
The question it started from was, in my words, “Is a training enough to change the way a department works?”. My answer is below.
An Amazing Software Architect Is Coming To Romania
38 months ago
One year ago, I had the chance to be invited to speak at the second edition of Agile Portugal. I had no idea back then, but my view on software architecture was about to change for good.
Refactoring Keeps Functionality Intact
01 year 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?
