Antagonistic Pleiotropy

Yet Another Validator

2008-09-20T06:26:00.000-07:00

Sick of writing validators? Sick of XML? Sick of framework specific validation? Sick of complex formats and extra stuff you never use? Well, I was too and now I've outsourced something that might help you too reducing these pains.
Check out YAV.
YAV is a simple, framework independent, lightweight Java validation tool. It applies validations directly to domain models through annotations. It checks for mandatoriness, email, range and regex. If you need, create your own methods to perform more complex validations. It is JSR-303 non-compliant - thank goodness :)
Currently integrates nicely with Spring2.5, Struts2 is on the way.
It also has ValidationTestCases that minimize annoyingly repetitive testing tasks.
As always, there are a few edges to trim, but it works.

Momentary Autism and Business Blindness on Software Development

2008-08-11T01:45:00.000-07:00

I finished reading Blink a couple of weeks ago and the anecdotes keep on coming back to me all the time. The book has several support stories for the author’s arguments and in general they are very well constructed. There is one in especial that is closely related to software development. It is the one that talks about how police officers get into a state of momentary autism on situations of extreme pressure. Far from me saying that software developers are under the gun in the same fashion as police people, but there are similarities.

In the book Gladwell discusses why highly trained professionals can bluntly fail to recognize true danger. The most probable reason is that once inside of complex situations the human mind tends to fail intercepting external stimuli. He suggests that a way to avoid getting caught on such mind blanking traps is to repeat safety steps. Most people can handle complex situations but few know how to avoid creating them in the first place. In software production, frequent codebase commits and updates, rigorous test writing (preferably in TDD way) and the use a continuous fast build are as important as keeping a gun away from suspects or holding the torch with the weak hand. If the process provides safety use it always.

In his research Gladwell found that police officers working in pairs do things differently than those working alone. Actually partners tend to speed up when working together. For the police speed can be bad because failing to correctly interpret signals in life threatening situations may be disastrous. Software, on the other hand, needs to be produced quickly, so let’s pair. Developers working together are more confident and like police officers tend to be bolder and charge more. It's a pity that police doesn’t have test frameworks to find out if the suspect was holding a gun or a wallet by the time they decided to open fire.

The autistic condition reported by officers has striking resemblance with the business blindness that plagues developers. Officers say that the fear of gunfire is such that they react without considering external factors. They are trained gunmen but the last thing they want is to fire a gun. Don’t go on writing code unless you know it has business value. It is every developer’s job to challenge requirements for purpose and need. Don’t allow yourself into a condition where everything is self-justified. Don’t use your experience to simply write more code instead make sure that every line delivers value.

2008-07-26T00:58:00.002-07:00

This is a list of things to note when developing Rails/JRuby applications that will be deployed to java web containers such as Tomcat, WebSphere et alli. It's obviously incomplete but it is much longer than I thought it would be when I first started.

RAILS_ROOT becomes the context therefore your traditional Rails folders aren't where you'd expect them to be. In a java container the public area is usually context's root. Warbler helps be copying the files from the application's Rails public folder and you can also modify how it packs the app by changing the entries in warbler.rb.
Rails caching usually depends on where public files are and things tend to go bezerk unless you set where the public folder lives. So, place this in your environment.rb: Rails.public_path="#{RAILS_ROOT}/.."
Try to stick to one interpreter only. It's quite confusing managing dependencies and versions when having too many rubys installed, and it's very easy to end up with:

the IDE's JRuby
the JRuby you installed
the JRuby that comes with warbler
the C-ruby install

Assuming the app will run in JRuby prefer NOT to use a C-ruby interpreter at all, not even in development. This doesn't necessarily means giving up Mongrel/Webrick. Java containers won't refresh changes to view files so it is very handy to use Mongrel/Webrick for the minor css/html changes, otherwise you'll loose rails quick feedback cycle.
Make sure that the version you're developing in is the same the app will be running when in production.
Don't use warbler's (v. 0.9.9) JRuby version (1.1.1) it will most certainly cause you grief. Delete it from the installed GEM and get the latest jruby-complete.jar, then place it in the lib directory so warbler picks it up when packing the war.
Check config.webxml.rails.env in warble.rb to make sure the warbled app is configured with the environment you want it to be. This variable creates an entry in the generated web.xml that defines which RAILS_ENV will be executed.
JDBC adapters seem to be a problem still. When running RSpec the test environment crashes because recreate-database method isn't implemented yet. It seems that Derby is the only one fully implemented.
Gems dependencies (Rails 2.1) aren't working properly. It seems that it has issues with java gems. I failed to install/unpack hpricot and activerecord-jdbc. So use other ways to freeze gems into the project. Don't forget to use config.load_paths to tell where the gems are in relation to the app in the java container.
Deploy as frequently as possible to the target java container to avoid surprises. I can assure you that there will bad surprises if you don't do it.
Autotest (ZenTest) doesn't seem to like the script/spec command. A cheap way to overcome this is to create a softlink called script in JRuby's bin directory that points to the bin directory itself.
I'm using H2 (file based) in development and it is a cool database but there is one annoyance in Windows. Windows locks H2 log file even if the connection is explicitly saying that it shouldn't - url: jdbc:h2:file:db/development;FILE_LOCK=NO. In Linux/MacOS it behaves properly.
JNDI resources are available for databases only, if you need to grab a hold of other JNDI resources some code has to be cooked to do the lookup. I wrote this very simple JNDI adapter.
Let database adapters do their jobs, it's a little more code but it guarantees you won't run into type conversion problems. For instance:

GOOD -> Person.find_by_name name, :conditions => ["alive = :breathing", {:breathing => true}]
BAD -> Person.find_by_name name, :conditions => ["alive = true"]

Use Exception Notification. It provides a very nice snapshot of the state of affairs and you'll need it.
Use HAML, it really makes things simpler. This not a JRuby thing but a still a good recommendation.
Pay attention to links. Strive to use rails resolvers to create links and urls, as traditionally, in a java container you'll usually have a context. In regular rails it looks like this: http://localhost:3000/persons and in java-land most likely this: http://localhost:8080/appName/persons
Netbeans 6.1 made me smile after frustrated weeks using Aptana and E. I know IDE's are religious war starters but this is my take on it. Netbeans works the others don't.
If possible prefer NOT to develop in Windows, especially because it is definitely much slower. If you must use Cygwin. BTW there is this cool tool called Terminator, it keeps all terminals together in tabs.
I had problems making controllers see some modules. More specifically cache sweeping. In my controller I had to add these 2 lines, or it doesn't work:

require File.expand_path("#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/caching/sweeping") unless defined? cache_sweeper
include ActionController::Caching unless defined? cache_sweeper

Protect from forgery has problems with WebSphere. It always complains about the generated tokens not been compatible. Is any one using it?

Slight difference on defined? results

2008-06-24T05:46:00.001-07:00

Some piece of ruby logic was depending on a defined? check to identify local-variables. It was working fine in C-Ruby but it failed when ported to JRuby.
So what we found out was that the defined? keywork/method/check/thingy in JRuby gives a slightly different response.
Try it out. In your terminal bring up irb and type:

Then try it with Jruby:

JRuby spits out a local-variable(in-block) whilst C-ruby gives back local-variable only. I suppose this is intentional, although I didn't go down the rabbit hole to confirm it. If you know the rationale I'd like to know it too. Anyways, just a heads up that they are different.

Reading JNDI resources in JRuby

2008-06-23T06:42:00.000-07:00

The most common use of a JNDI resource in JRuby-land is for configuring datasources. But now I wanted to have ActionMailer send emails using a JNDI config. So how to do it?
Do not fear! JRuby is your friend and every old java trick can be used.

So let's create the JNDI resource which is an javax.mail.Session pointing to localhost. This is what one would normally find in Tomcat's context.xml file (pastie):

Then let's create an adapter to do look ups for us (pastie):

And finally a simple test to see if it works (pastie):

Pretty easy huh?

The Omen strikes again! JRuby on Rails on, yikes, Websphere.

2008-05-27T03:23:00.000-07:00

Recently I kept my self busy, and highly frustrated trying to get a JRuby application working on WebSphere 6.1. The recipe was pretty straight forward: warble it and deploy it. Truthfully, there are a few steps that you need to be taken care of, such as configuring database.yml to point to the right place and making sure warbler.rb config file includes the proper jdbc-adapters, but that is all OK.

So, after trying the generated .war in Tomcat and confirming that it was working fine, it was time to hit WebSphere land, and guess what!, didn't work, duh!

The default web.xml configuration doesn't play well in WebSphere. The worst part is that there are no error messages, not even a trace in the logs to help.

The default web.xml spat out by warbler reads:

The filter doesn't work in WebSphere, but the servlet does the trick. So I changed the web.xml.erb within the installed gem to produce this:

Note that I've repeated the listener tag, it was intentional. WebSphere will complain if the listener declaration came after the servlet tag, it must be before, duh! again!

IBM - DB2 - Blobs - Hibernate - Truncating - Yikes!

2008-05-14T04:06:00.000-07:00

Every project has its caveats but those that use DB2 have the omen!
Yes kids, it's rant time. Why do IBM must make developers lives through out the world so miserable? To the hell with bloated enterprise software.
After wasting time trying to figure out why Hibernate was having problems inserting blobs into DB2, our team realized the obviousness: blobs must have their size defined, no duh!

So imagine a domain object that reads:

@Entity
public class Image {
@Id @GeneratedValue(strategy = GenerationType.AUTO)
private Long id
@Lob
private byte[] image;
}

To work in IBM/DB2 land it must read:

@Entity
public class Image {
@Id @GeneratedValue(strategy = GenerationType.AUTO)
private Long id
@Lob @Column(length = 1000000)
private byte[] image;
}

And pray that your bytes don't get to big or you'll need to recompile your domain.

True-blue Agile team

2008-02-08T05:36:00.000-08:00

Yesterday was Iron Maiden's show. <scream> Maiden </scream> And I was there *grin*. Aside stating the obvious that it was an awesomely great show, they put me to think: why some bands, or groups of people more broadly, achieve success while the majority doesn't?

What’s the recipe? Is it talent? Is it the hard work? Is it never giving up? All of the motivational aspects are probably there, but I'd say that the common ground is that, most invariably, great teams didn’t start off great. They learned how to be great together. Team learning is key to a team’s success. Individuals have their unique capabilities and may even be the best in their fields, but unless they learn how to play together nothing really happens.

A true-blue Agile team-player knows that the team comes before the individual. As Mike Cohn says: “…the team must precede the roles”. “I’m in project XZY as a developer.” is very different than “I’m a developer assigned to project XZY”.

Another import aspect is that the sense of accomplishment has to be shared. If one person tries to take credit for the success or play the blame game when things go wrong, then that person isn’t a team-player.

As lastly non team-players must leave. Those who don’t want to learn how to be a team should go away. Keeping around people who cannot orchestrate their actions and thoughts will take toll on the whole team. But don't feel bad about it there will always be enough space for those who like to work in solitude not sharing their sufferings or findings.

OK, so it’s all about creating a synchronized learning team, but how do we achieve that? There are many lines of thought on learning organizations, IMO Peter Senge is a great reference, but is it enough to create a first class Agile team? Are Agile teams learning teams? And finally, can we apply Agile techniques to help teams become Agile? What do you think?

Technical Debt is a cancer

2008-01-29T05:10:00.000-08:00

After a discussion about Technical Debt (aka TDebt) in Thoughtworks I realized something: Technical Debt is just like cancer.

There are several similarities between the disease and this "condition" that happens quite frequently in development projects.

There is a line in medicine that says that if you live long enough you will develop some sort of cancer because organisms have intrinsic failures that will manifest themselves if enough time is given. An IT project that lives long enough will present TDebt related problems.

Cancer can develop from external factors or congenital predispositions. Tobacco, sunlight or too much tuna can disturb your organism to a point of metastasis. Less than good design/coding decisions affect the general project’s health in similar way. If the team chooses to cut corners and develop bad code intentionally TDebt will build up. As for the congenital problems that may be circumvented by using some tools. From a Java angle it can be FindBug or PMD to continuously inspect congenital problems related to the technology stack of choice.

No one wants to discover a cancer but once you find it you need to take some action or it can have terrible effects. Tackling TDebt is hard and many choose to put it off until it's too late. However if the case is a terminal one, then nothing can be done. All you can hope for is for it to live long enough to fulfill its purpose. Different types of problems require different procedures. But seems that the most popular and successful approach is: isolate and remove.

Early detection and prevention are key. The sooner the problem is identified the easier it is to heal. Regular check-ups are a Good Idea™. If a potential problem is detected it should be examined to determine whether it is benign or malign. After that one can decide the course of action. Also there's no point in being a hypochondriac, this shouldn’t consume the team’s time away, it’s preventive not obsessive.

Some people get worse after they discover a cancer because their moral gets shot. Projects slow down because of TDebt, which gets devs very de-motivated. TDebt makes things unnecessarily complex turning simple tasks into major efforts. Anything that impairs people from living normal lives have devastating effects on their will.

When do you communicate to your family and friends? To what extend TDebt should became visible to the business? I'd say that the approach depends on the severity of the case. Less seriously cases can be treated internally without making a big fuss, but if more people, money and support are going to be required to reestablish the healthy state then stakeholders need to fully participate in the process.

Bottom line, have healthy habits (TDD, simple design), prophylaxis (refactoring), use tools to monitor congenital problems (FindBug/PMD) and frequently consult your doctor for a code health check-up.

HashMap temptation

2008-01-27T07:31:00.000-08:00

When integrating systems it is very easy to fall into HashMap temptation. “Just put some details in a Map and pass it to the service layer and it gives back what you need”. Maybe,… but there are risks.

I consider passing Maps around to services an anti-pattern because interfaces become less intentful and creates coupling between layers.

Let’s consider a hypothetical example of a farm system. Every morning old McDonald wants to name roll call all animals to ensure they are safe and sound. Farmer McDonald knows he has animals in the pond and on the pasture.

On the first pass we create a service receiving a context Map, keyed by environment type and containing animals’ names. The service returns a List with farm Animal instances.

Old McDonald knows the animals’ names, where they live and expects them to say: “present”, in their own dialect, obviously. One client program could look like the one bellow:

With this implementation it’s impossible to have a pond roll call only. But that’s not the worst thing, knowing that the service needs to be aware of different environments and keep track of them is the creepiest part. One solution is to make the service layer more intentful and have old McDonald say explicitly the animals of which environment he is roll calling:

Now instead of a Map it’s a List that gets passed around, the service interface expresses *exactly* what’s to be done and code can be re-used. The downside is that an extra call needs to be made from the client. In this particular example it’s not a major hassle because it requires no extra information about the livestock:

Bottom line: avoid passing Maps around and put more effort into defining highly intentful interfaces. As a rule of thumb service layers are dumb, hence they don’t have to decide which method/logic is to be invoked based on states/keys of other objects. Service layers should only know about domain objects and which methods to invoke. Utilising HashMaps in similar ways to this example violates the Tell, Don’t Ask principle. This design forces service layers to understand what’s inside of Maps to decide which method to invoke and the client layer in its turn, must create Maps with all things the service needs in order to process the call, which smells like coupling.

Why Agile adoption fails?

2008-01-25T14:20:00.000-08:00

Why some seem to succeed to produce quality software using lean methodologies and others don’t?

For starters there’s a giant lacuna between acknowledging that Agile is useful, fast, high quality, etc and been truly Agile. For Agile to work one must believe and *act* according to her beliefs!

I’ve noticed that teams fail to create software using lean approaches mainly because of their preconceived mindsets towards an apparently less predictable, although more precise, model.

Unfortunately no one can build software as if it was a house. In software construction you *can* have your own voltage, no gravity and wine instead of water running in the pipes. Therefore managers need to accept that will this level of freedom there is a proportional level of uncertainty that cannot be cleared upfront, regardless of the effort put into planning and estimating.

A forcefully preset release date on a spreadsheet means very little to software development. In the outset it only expresses a desire. Functionalities need to be sized, time must be derived for sizing and then, only then, a date estimated. Even after that, realize that that’s all it is, an estimated date.

Trying to re-estimate stories because they’re taking longer than expected is another contributing factor for disaster. Let velocity do the work of defining progress, story size cannot change speed.

Teams have a hard time accepting that there’s only so much that can be done to go faster in order to meet a deadline. Reducing complexity is one option, re-prioritizing and re-scoping too. Resizing your team can also have positive impact, but overtime not. By working long hours quality will inevitably be compromised and reducing quality is not an option in Agile.

Some say Agile is too informal, and even that it makes the office space look ugly with all of those cards on the walls! Software development has always been messy and Agile only exposes it so people can act upon it. Agile is formal, as formal as the organization using it wants it to be. And yes, there is planning too. I don’t have figures but with Agile there’s more planning effort than waterfall. The difference is that the planning is diluted in everyday work such as stand ups, technical huddles, iteration planning meetings, kick-offs, planning poker, etc..

Agile is highly dependent on talented developers. Roles such as team managers and architects have less or no impact in Agile teams. Traditional waterfall micro-management kills creativity and architects tend to do a lot of upfront design and create unacceptable resistance to design change over the course of stories. The devs need to be different too. Agile devs must be design savvy, have creativity and initiative.

Lastly, if all of this seems too daunting and you don’t want to take the risk of figuring out Agile heuristically, go and hire an Agile consultancy. Get people with experience to help you out in a few projects and inculcate the principles. This way the organization gains confidence, establishes a faster return of investment and creates enough in-house Agile champions to sustain the changing momentum throughout the company.

Swing Acceptance Testing with JFC

2008-01-20T22:08:00.001-08:00

After many years developing for the Web I found myself having to do some Swing code and *obviously* had to do some testing for it. I went with JFC for the functional tests and here’s a little cookbook.

The test class extends from JFCTestCase

public class CurCalcTest extends JFCTestCase

The main JFC class to take heed is JFCTestHelper. Probably a Good Idea is to set it in the setup method:

protected void setUp() throws Exception {
super.setUp();
setHelper(new JFCTestHelper());
}

After that, my approach was to get the container under test/investigation:

JPanel curCalcPanel = (JPanel) frame.getContentPane().getComponent(0);

And then obtain each one of the elements I want to manipulate, such as comboBoxes, textFields, and etc.:

NamedComponentFinder amountFinder = new NamedComponentFinder(
JTextField.class, "jTextFieldAmount");
amountField = (JTextField) amountFinder.find(curCalcPanel, 0);

NamedComponentFinder countryComboFinder = new
NamedComponentFinder(JComboBox.class, "jComboBoxCountry1");
countryCombo = (JComboBox) countryComboFinder.find(curCalcPanel, 0);

NamedComponentFinder messagesFinder = new
NamedComponentFinder(JLabel.class, "messages");
messagesLabel = (JLabel) messagesFinder.find(curCalcPanel, 0);

Now I can insert my keystrokes/clicks using the helper:

getHelper().sendString(new StringEventData(this, amountField, "1"));
getHelper().enterClickAndLeave(new JComboBoxMouseEventData(this,
countryCombo, 1, 1));
getHelper().enterClickAndLeave(new MouseEventData(this, convertButton));

And assert my expectation(s):

Assert.assertEquals("0.97478773", messagesLabel.getText());

JFC is another fantastic tool by ThoughtWorks. It is a very useful framework but not friendly all of the time. For instance, if you forget to identify the elements properly via the setName() method, and try to use NamedComponentFinder no error is given, the thread just sits in there without complaining about anything.

New Year's resolution

2008-01-05T02:46:00.000-08:00

Is it too late for a New Year resolution?? Probably not. Then here it goes. I'll learn Ruby in 2008. These are the reasons:

I'm getting a bit tired of Java and Ruby seems to be the next logical move
Now that JRuby is out, chances are that the Ruby will really make to corporate environments
It has a strong community
ThoughtWorks is supporting it wholeheartedly, BTW welcome to the team Ola Bini!
Ruby is very flexible allowing some very fancy things, still lacks a bit of control thou
Finally and most important, Ruby is Agile

So Ruby, here I go!

Notes on Selenium-grid

2008-01-02T16:50:00.000-08:00

The fact that web tests, let’s call them here Selenium tests, are time consuming seems to hurt a lot of agile projects. Long build times are hard to live with.

In the early stages of the project there are a few Selenium tests, usually not very well structured and testing on a per story basis. As more stories are played more Selenium tests are created, usually with a certain degree of repetition, causing the build time to increase. That’s when it starts to sting.

In my last client the build time started off in the thirty minutes range and after four iterations it was costing the team a horrendous seventy minutes. Selenium tests alone were responsible for almost fifty minutes.

There were a few ways to reduce time. The first obvious one is ditching some tests. If you are playing by the book and doing TDD, really caring about your unit and integration tests, and have a decent test coverage, giving up a couple of redundant tests might not be so bad. Another option is to rewrite tests to eliminate redundancy and test using a scenario approach instead of the story one. Scenario based tests are a Good Idea™ but time consuming and hard to guarantee that everything that was tested before is still been tested using the conceived scenarios. A third option was to parallelize the tests and Selenium-grid allows doing just that.

Lawrence Song and I had Selenium-grid up and running with no traumas. It’s quite straight forward to install it but not all is roses. Web tests that run on a farm need to be more carefully constructed that those running on a single threaded environment.

Tests must run atomically and the rule of one behaviour per test should be strictly observed. For instance, if tests perform database operations on the same data they can have problems when running concurrently.

Don’t leave Selenium objects hanging in there. Selenium objects that aren’t closed properly causes the hub to stop sending RC commands until you have only one Selenium server available. So the Selenium lifecycle needs to be managed more tightly.

You need to think about the test list. In order to use the grid’s capabilities tests need to be run in a multi-thread fashion. TestNG does a better job that Parallel JUnit. Some Gargoyle like facility would help make it more manageable. As a last resource, which seems to be the sensible one especially when needing to avoid two or more tests running concurrently, is to use parallel ant task and pick your tests using a pattern.

Web tests are generally CPU intense and it’s a Good Idea™ to think about how many Selenium servers should be running on each box, especially if they are also running other apps like your container for example. We saw flaky results when boxes where running close to 100% CPU all the time.

Bottom line is that Selenium-grid is a great help to solve a common problem, in our client the build time dropped significantly and now takes around twenty five minutes with a few hours of effort. Yay! And we can always add more boxes. Selenium-grid has a very positive side effect which is to reinforce better test design.

Nevertheless I’d really enjoy if Selenium-grid could provide the community with the ability to utilise idle computers to run tests and a friendlier interface to manage the hub.

Don't skimp on defining ids in your DOM

2007-11-20T02:33:00.000-08:00

Recently after updating from Selenium RC from 0.8.3 to 0.9.2 I noticed some serious performance degradation, actually in an order of magnitude slower. Tests affected the most were those using XPath to match attributes. These tests were doing too broad searches by using '//*' such as in '//*[@id='errorField1']/td[2]'.

As a fix searches were narrowed by providing a more specific search, such as '//tr[@id='errorField1']/td[2]'.

Locators starting with '//*' search any element node from the current node that match the selection no matter where they are, been therefore very expensive.

So the general recommendation is: be specific. Try to provide the node you want directly, ideally, a specific id should be provided, i.e. 'id('errorField')//' (although there are known issues in IE6).

Despite the fact that I'd rather see a better performance when advancing versions, the moral is: don't skimp on defining ids in your DOM, the more the DOM is properly marked the easier and faster it is to be tested. Keep in mind that acceptance tests are time consuming and performance improvements are greatly appreciated, especially if you run them as part of your continuous integration build.

Few pointers on refactoring

2007-10-29T02:09:00.000-07:00

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

2007-10-26T18:20:00.000-07:00

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

2007-10-23T06:29:00.000-07:00

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

2007-10-19T05:15:00.000-07:00

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

2007-10-15T23:43:00.000-07:00

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.