Exploratory Refactoring - Understanding Legacy Code

Remember how Neo can see people and places and events behind the code? Well. Not all of us mortals can see the shape of things at first glance of code. Actually, "He's the One".

Martin Fowler suggests refactoring code when trying to understand it. Also Michael Feathers describes lots of techniques to work with legacy code. This post is about step zero: understanding the legacy code.

Exploratory Refactoring is the act of applying a series of refactorings to legacy code merely to understand what it does. That's it. There is no magic here. After you understood the inner workings of the code in question, you typically throw away all of that refactoring and start to really and seriously work on the code. With end-to-end tests, unittests and the whole shebang. But I'm getting ahead of myself.
I typically start off with simple refactorings, like Extract Method, Decomposing Conditional, Rename Method, Rename Variable, Introduce Explaining Variable. This phase is like when an archeologist hand-cleans stuff during excavation. She might already have ideas of what each part is, was, but that's not the point. In this phase she just wants to make the parts as apparent as possible.
In our case however, you don't have to be very careful - as this is a throw-away refactoring - in extreme cases you could just pseudo refactor the code. However the closer you get to real-life refactoring, the more you can learn from it. You will get to see unexpected inter-dependencies, which  can influence your real refactoring later on.
Once you have done that, you can start to fit the pieces together and you can continue to dig deeper - or go higher in terms of abstraction  - , and use more complex refactorings which help you to unveil the intrinsic structure of the code, like Consolidate Duplicate Conditional Fragments, Remove Control Flag, Split Loop, Reverse Conditional. It could be that after quite a few refactoring, you still don't see structure or intention: Worry not! You will see it soon. Just keep on factoring each small bit of information back to the code.

One last bit of advice:

Don't make the typical mistake of dissing and cussing the author(or the poet we like to call them) of the legacy code. Not because it's simply bad manners, and not because we all have legacy skeletons in our careers  closets, but more importantly, because that way you distance yourself from the poet of that code, making it that much harder to see what he meant to say, when he for example named a variable $last_element. 
(Whilst if you try to indentify with him, you might realize, he really meant $previous_element )
Read full post...

Dan North misses his own point?

Dan North is one of my favorite tech speakers. He is funny and entertaining as well as thoughtful and subversive. He gave a speech at NDCOslo about Embracing Uncertainty. He states that risk has two important aspects: Probability and Impact. Then he observes very astutely how most of us in IT focus only on minimizing probability and why that focus is misdirected. His reasoning is that you can never decrease the probability to zero so you should focus on minimizing the impact. It's a typical Dan North observation: almost embarrassingly simple yet very refreshing and eye-opening, which puts conventional methods into new perspective. This kind of ideas are the very reason I like him so much. Then he goes on to describe a few techniques with the help of which we are supposed to embrace the uncertainity of effort and uncertainty of technology and so on.

The first technique is called Real Option where you treat everything as a financial option, so that the later you make a commitment the better chance you have to make the best decision. You notice the word 'chance' in the last sentence. This method is very similar to the Last Responsible Moment and one that you should use, but it's optimizing for probability and not impact.

The other one is called Deliberate Learning where you try to find the areas in which you might be subject to second degree ignorance, in other words areas where you don't even know what you don't know. He emphasizes that there will always be stuff we don't even know to be unknown, yet he wants us to try to know anyway. Again, in my opinion this technique is aiming at minimizing the probability of things going awry, and not the impact of a possible mishap.

He's picking a little on eXtreme Programming in this very talk for trying to embrace change instead of uncertainty. I find it ironic because many of the XP practices and principles are about minimizing impact. The Iterations, Incremental Design, User Stories, Baby Steps, Short Release Cycles, Done Done. All of these are based on the simple idea that the smaller you can make the completed chunks of your product the smaller impact of any possible mistakes will be.
Read full post...

Agile in hostile environment

It can be tricky to apply agile methods in a fundamentally waterfall environment. So tricky in fact, that we might be better off without agility.

Agile Manifesto was created to help creating software of value, which - according to the founders - required a different approach and a different set of methods altogether. The neccessary shift of approach was expressed in nice and clean preferences from wich the methods are more or less directly derived. If because of the circumstances we cannot make the shift in the approach, using the methods stubbornly makes little to no sense. I start with the easy ones, see if I can ruin it all for you..

(1) If the deadlines and the scope is fixed, moreover you need to deliver certain results (documentation, software, test results, etc) at certain times, you are following a plan, instead of responding to change.

(2) If you need to provide detailed req.spec, estimations, design documents, etc, then obviously working software is only of second priority, since the signing and the delivery of the contract relies heavily on these documents, rather than on working software itself.

(3) If you have to have the req.spec and the corresponding estimations upfront, you and your client - forced by contract - are bound to them(i.e. requirements and more or less estimations too). And then with even the best intentions you can get your client involved in the preliminary discussion only which are theoretic almost by definition.

(4)I left the toughest one for last.
The sobering truth is that - and a sick plot twist is around the corner, you better watch out - in such a hostile, anti-agile environment, as the above depicted one - applying agile tools and processes, in fact might be the wrong choice, and for the wrong reasons too. Because this in itself goes against agile principles in that it chooses processes and tools over people, who can't enjoy the benefits of agile methods, nonetheless have to invest the extra effort they demand. And almost all of it is completely in vain, as the software won't be any more of value than it would have been with traditional methods, because it will turn out to be exactly the thing that was required/designed/estimated/agreed-upon before any line of code had been written and/or tested.

Read full post...