Few pointers on refactoring

If refactoring isn’t a part of your daily life you may find it a bit hard to know what to do. There is also that fear of messing up code that is working properly. Well, the later can be eased by having extensive test coverage. The more tests the codebase has the safer the refactoring will be. And for the former I tried to put a few pointers here. This isn’t a complete list of refactorings though, it is just a start.

• Read the class and try to understand it.
• Is the class responsibility clear? Or is the class doing more than it should?
• Are there fields been accessed directly by other classes. If yes encapsulate.
• Do the public methods have meaningful names? Are they aligned with the class’ responsibility? If not extract to Helper class.
• Check if public methods really need to be public. Always Ctrl+Shift+G to see who’s referencing it.
• Mind visibility modifiers. Ensure you have a reason when using public, protected or default.
• Is the class been instantiated in more than one place and does it have subclasses? Considerer extracting an interface.
• Duplicated (or very similar) code? Extract a method. Rule of thumb: DON’T Ctrl+C, Ctrl+V as it leads to Code Horror ™.
• Do private methods contain class specific or do they look like a util-type of code? If yes move it to a proper class.
• Util classes are singletons or static methods, we shouldn’t need to instantiate utilities.
• Extract methods from the if’s conditional clause, body, and else parts. Avoid complicated ifs and elses as they usually clog the code and create unnecessary duplication. Think about using Strategy.
• Check for extends. Can I compose instead of inherit?
• When using methods from different interfaces in a complementary way consider writing a Façade to join the two (or more) of them
  
• Don’t wait for a NullPointer to explode the stacktrace, use Assert.

Every problem is a people-problem

A friend of mine who just starting working in an Agile project said to be worried that all problems in the project seem to people problems. I started to think about project problems. Technologies? Time and money constraints? Quality? The list can go on and on. However the bottom line is that people will have to code the solution - I know it's a simplistic view but computers will do nothing by themselves - and assuming that a minimum level of sanity was applied while establishing the deliverables, everything else must be people problems then.

Don’t believe me? Take Kent Beck’s words for it then. In his book XP Explained he says: “… no matter what the client says the problem is, it is always a people problem.” Ok now that I’m on giant’s shoulders let me try to make my point.

What bogs velocity down?

Interruptions – people are taken away from what they should be doing, justifiably or not. Illnesses or life administration matters.
Over commitment – one promises to do more than can actually be done.
Fear/Resistance to change – I already know this technology/methodology and changing threatens me
Bad sloth - In opposition to Good sloth which I’ll write later, hopefully :0) – I’ll only do the minimum and if I can I’ll do nothing.
Tedium – I’m so damn bored I can’t motivate myself to do nothing.
Over engineering – Pythagorean Switch syndrome.
Excess of political concern – If there is no positive press I won’t do it.

The scales tilt to softer aspects and not to technical ones. Once we admit it and put effort into really understanding the team-members, their frustrations, aspirations and turnons we might be able to successfully remove most of the hurdles that hinder software development.

We don’t stop to refactor, we refactor to not stop

I don’t think I can reinforce this enough. Agile teams refactor.
Refactoring is a core practice that underpins Agile development. As a refresher: Refactoring is modifying code without altering system functionality. This means that if all your tests are running properly prior to a refactor exercise they should not require any extra work once refactoring is completed.
Refactoring contributes directly to internal quality, which is of course, non-negotiable in an Agile endeavor. Internal quality guarantees a steady velocity and maintainability throughout iterations.
The main reasons why some developers still vacillate to refactor mercilessly are lack of trust in the IDE capabilities and the assumption that “it can done later”.
You should trust your IDE or switch to one that you feel confident with. You’ll only gain confidence by understanding the IDE capabilities and practicing them. Therefore dedicate some time to study the refactoring facilities and write several examples to practice.
Refactoring is not an activity that can wait until a story or project is completed. No project has exclusive budget for Refactoring and because it does not deliver any extra functionality it's virtually impossible to convince sponsors to finance it.
Bottom line, Refactoring is an ongoing practice and the cliché still holds valid: “We don’t stop to refactor, we refactor to not stop”.
Happy refactorings :0)

Distorted project velocity and skewed story points

How to increase project Velocity the wrong way? Just distort Story Point estimations to be more than what they really are. Story Points are not for that. And using Project Velocity as the only fixed goal may bring disastrous results.

Story Points represent a story’s complexity when compared to other stories. Yes, Story Points need comparison. Why? Because complexity it’s intimately related to the team’s technical capacity, gel, motivation, etc. Story points are not units of time, but people will, most invariably, relate the two. That’s not too bad as long it’s not used for the purpose of creating slack or artificially increasing velocity.

Agile teams should be aware of their estimations and should never allow intentional inflation of Story Points under the risk of creating a demotivated environment, not the mention that this will discredit the the team to managers and executives. If the team insists on this practice it's better go back to time units. At least it's real.

Title explained

The term Antagonist Pleiotropy is misused in this blog. It represents a genetic situation used in G. C. Williams theory of aging. I first learned about it while reading Bryan Appleyard's book "How to live forever or die trying" (pretty interesting by the way). I'm using it with the single purpose of an alert. An alert that whatever you do/have today that is currently beneficial might not be in the future, in fact it can potentially ruin you completely.

Nevertheless now that the title's obscurity has been properly explained I can start :0) This blog is about software development. Yep another another one. I should have called it YATB - Yet Another Tech Blog. I promise to try and make interesting though.

I'll blog about Agile, lean processes, Java and anything that helps relieving the pain of creating decent software.