Deprecated: Assigning the return value of new by reference is deprecated in /home/melaloui/public_html/ueckerman/wp-settings.php on line 520

Deprecated: Assigning the return value of new by reference is deprecated in /home/melaloui/public_html/ueckerman/wp-settings.php on line 535

Deprecated: Assigning the return value of new by reference is deprecated in /home/melaloui/public_html/ueckerman/wp-settings.php on line 542

Deprecated: Assigning the return value of new by reference is deprecated in /home/melaloui/public_html/ueckerman/wp-settings.php on line 578

Deprecated: Function set_magic_quotes_runtime() is deprecated in /home/melaloui/public_html/ueckerman/wp-settings.php on line 18

Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1244

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/classes.php on line 1442

Strict Standards: Redefining already defined constructor for class wpdb in /home/melaloui/public_html/ueckerman/wp-includes/wp-db.php on line 306

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/melaloui/public_html/ueckerman/wp-includes/cache.php on line 431

Strict Standards: Declaration of Walker_Comment::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/comment-template.php on line 1128

Strict Standards: Declaration of Walker_Comment::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/comment-template.php on line 1128

Strict Standards: Declaration of Walker_Comment::start_el() should be compatible with Walker::start_el(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/comment-template.php on line 1128

Strict Standards: Declaration of Walker_Comment::end_el() should be compatible with Walker::end_el(&$output) in /home/melaloui/public_html/ueckerman/wp-includes/comment-template.php on line 1128

Strict Standards: Redefining already defined constructor for class WP_Dependencies in /home/melaloui/public_html/ueckerman/wp-includes/class.wp-dependencies.php on line 31

Strict Standards: Redefining already defined constructor for class WP_Http in /home/melaloui/public_html/ueckerman/wp-includes/http.php on line 61
ueckerman.net » 2004

Archive for 2004

Challenging Agile Resistance

{Thursday, December 9th, 2004}

I’ve been lucky enough to have experienced a number of development methodologies in my time, ranging from straight forward Waterfall, to a more iterative RUP style, to a pure-bred XP style. Along the way I’ve been reasonable enough to be open minded and accept other practices. Granted, I don’t think there’s even been a time when the transition was easy. There’s always questions, always pro’s and con’s, and there’s always my opinion regardless of what an organization chooses to dictate.

What’s made my transitioning between the methodologies more difficult is my relative stubbornness – an attitude that was prominent until I hit my XP days. It dissipated (although not completely) then, gratefully loosing the battle with the XP evolutionary mindset.

But, I digress. My point is this; my experiences have led me to believe, without doubt, that XP is is the best methodology I’ve worked with. From a purely selfish point of view, it acts in my best interest by allowing me to focus on what I’d like to do best – learn and develop software. From an organizational point of view, it acts in it’s best interest by delivering higher-quality, maintainable applications, with scope flexibility that is guaranteed to deliver what the business wants - I’m not suggesting other processes don’t do this, but they just don’t do it efficiently as XP.

So, with these beliefs in mind, I find myself working for an organizations that doesn’t practice XP. In fact, I’m fairly certain that before I arrived they had very little idea about the methodology and even it’s practices. Staying true to my beliefs, I’ve discussed a number of solutions to a plethora of project issues with the ‘Powers That Be’, and it’s no coincidence my suggestions have been grounded on XP practices. To date this adventure has taught me that my stubbornness is definitely no unique trait – no surprises there. Importantly, I now appreciate that XP is much easier to teach in a ‘viral’ form – it’s so much easier to understand it’s benefits by actually doing it. The tricky part is getting an organization over the initial hill and convincing them to test drive a practice or two.

I find arguing XP’s theoretical side is easy. For mind, the theory of XP is simple to understand. After all it’s based on long-standing, tried and true, common sense, industry best practices. So the theory isn’t the issue. Getting people to understand how the theory works in practice is. Here’s some highlights of resistance I’ve encountered to date:
- That sounds great, but in the current state of play, we don’t have the time.
- I’m not comfortable with Pair Programming - it doesn’t seem natural, I can’t work with others looking over my shoulder.
- I’ve never had to update my Big Upfront Design after an Implementation. I’ve always been right upfront.
- I believe it’s in a projects best interest to produce reams of documentation. They communicate important messages to a great variety of audiences.
- I don’t believe Practice X works on large projects or in large organizations.
- XP is too radical and promotes shortcuts.
- No thanks, I know this other methodology works for me.

Some of these points are plain old ludicrous and easy countered, others suggest you need to produce some empirical evidence to back up a claim, others still are a strong indication of a closed mindset. In these latter cases I find there’s no alternative but to walk away from the discussion with your objections duly noted – especially when your dealing with decision makers. I find the hardest thing about dealing with a decision maker is when it comes to opinion - theirs counts, yours doesn’t. You need to resort to hard evidence and fact, while, on the other hand, their opinion is good enough reason for them. I can appreciate that they’ve earned that position, but it serves to occasionally obscure them from seeking out and making better decisions. In some cases the decision makers can suffer from Sinatra Paralysis, they just want to do it their way and will naturally resist, finding ways to keep their vision intact. In other cases they can adopt a Whiteboard Approach and rarely practice what they preach, not feeling any pain at ground zero.

Still, regardless of the many setbacks, I’ve gained many positives from the experience of putting forward arguments for adopting XP practices. My positive opinion of it has been re-enforced in the search of counter arguments and justifications. I’ve been able to see, in practice, how it is very capable of solving the many problems more traditional methodologies can and do encounter. I’ve also been able to gain a greater appreciation of the decision makers reasoning and motives.

So, even though most of my suggestions fall on seemingly deaf ears, I pledge to continue making them – I see it as a win-win situation for me and the team regardless. It’s a win for me to put an argument forward and it’s a win for the team to at least considers potential process improvements it offers, regardless of their mindset. There’s always hope that they will one day both hear and listen.

I remember prior to starting my European expedition, The Trigger told me of a proverbial software development jungle on the free market. He believed it was very unlikely I’d uncover a project with a pro-XP mentality. At the time I agreed with him, but I was hopeful it wouldn’t hurt too much. Well Andy, you were right - and it doesn’t hurt that much, well….maybe a little :)
P.S. Many thanks to the organizers of the recent XP Benelux Day for re-charging my interest. It’s good to know that there’s plenty of other XP practitioners in the region.

Unit or Integration Tests?

{Wednesday, November 3rd, 2004}

Plenty of people fail to see the value in unit testing. As it discourages testing the real code working together they can’t see the value.

What if a method returns a value, for arguments sake the string “A”, and that value is passed to a method that has never been unit tested to expect “A” - how can you guarantee what the system will do?

My answer is this - if you haven’t tested a behavior the outcome is non-deterministic.

But there is a problem with the question - your unit tests should be testing all the vastly different inputs and outputs expected by methods. If an input hasn’t been tested, you can’t determine the methods behavior. Essentially you have an incomplete test.

So what if the application behavior changes in some way, and it’s possible for methods to pass around different values? Say you write an isolated test for the core new behavior, codify it, run your unit tests - you see green lights. Fine. You then run your acceptance tests and you see tests exploding everywhere - nothing but red.

My point is this - unit tests are not intended to test the integration of methods - they are intended to ensure the functionality of a method, based on expected inputs and outputs, is correct. They are of high value in isolating the root cause of problems. Theoretically, with excellent unit test coverage, if a method output is altered to be vastly different, the unit tests should fail for that method only.

What if the inputs are dynamic, for instance database driven - how do you test the application works with this data? The short answer is unit tests combined with making every effort to ensure the data is legitimate data the application expects. There are masses of tools that provide data cleansing facilities should the state of your data warrant it. Simple things, like guaranteeing types, length, null states etc., can be easily controlled through a nice schema. If you’re schema’s crufty, it will lead to all sorts of compromises in the application - I rarely, if ever, justify the effort insulating the codebase from a layer of cruft. Fixing the cruft is always the by far the easiest course of action in the long-run.

So what about integration tests? Do I find them useful? Absolutely. I still write integration tests for code integrating with external services, such as persistent stores - but I still test a single method, just as I do in unit tests. Any integration test invoking a number of source code methods reeks of performing the application logic - essentially you’re venturing into the realm of testing the test.

So what about testing to make sure the application hangs together? I think the best candidate for this is functional/acceptance tests, simulating user flows through the application. Integration tests exorcising a number of application layers are confusing, extremely difficult to maintain and generally not worth the effort in comparison to the effort involved in writing simple acceptance tests.

Confused Comments

{Monday, November 1st, 2004}

One of the most confusing things to encounter, especially when trying to parse already unfamiliar code, is the presence of commented code. And I don’t mean comments for descriptive purposes - rather code that been killed by a comment.

Why is it there? Is it something that will be needed in future - maybe, maybe not? What if it’s not used? Will it ever be removed? Who will remove it?

From my point of view the solution to these questions is simple - just get rid of it. It saves confusion. If you need to recover code from a previous version, seek the assistance of your version control tool.

Comments, for mind, should be purely for documentation purposes and adding clarity to code. Generally I find myself adding more comments the more unclear the purpose and/or name of the class/method/variable.

Since I started the habit of developing in this order: Test, Comment, Code - the improvement in the clarity of my code has been dramatic. I also find that small methods and classes (yea CheckStyle!), hence blocks with distinct responsibilities, makes code self-documenting by orders of magnitude.
Comments are important - but excessive comments is a sure sign that something smells like fish - and I hate seafood.