As anyone who reads this blog knows, I’m an extreme programming enthusiast. I love pair programming, test driven development, and the constant communication with customers. it’s one of the reasons I took up a job at my current employer, because it is an “Extreme Programming Shop.” However, for awhile now I’ve heard a bit of bickering from some that “we don’t do XP”, or “we don’t do XP by the book,” or perhaps even “XP doesn’t work for us because it’s wrong.” Ouch!

An important thing I have learned is that how well your team does with XP is how much your team buys into it. It doesn’t matter if management jumps on board or not, if your team members don’t hold each other accountable to the practices, if they let each other get away with not pair programming, writing code without any tests, and limit their customer communication, OF COURSE they aren’t doing XP. And that’s the difference.

In my last department, we saw quite a few changes in team structure, and I think I hopped around to 3 or 4 different teams there. There were teams that I almost felt that we weren’t doing XP at all, and was frustrated. But then I switched to a smaller team (from 8 people to 5) that included people who were zealous about XP like me… we made it a general rule that if code isn’t checked in by the end of the day, it must be deleted. This kept us going fast and releasing small changes that could go to production after check in if need be. We kept each other from “cowboy coding,” if one of us were stuck as the odd developer, the solo person would either do some data analysis, pair up with other teams if needed, or go ahead and spend a session talking to the customers and showing them our acceptance tests.

The point I’m trying to drive to here is that it doesn’t matter what your manager tells you, it doesn’t matter if the company has bought into XP or some other agile process. If the team doesn’t truly embrace the principles, you’re right… you aren’t an XP team. Just as much as you’re not a football team if your team members aren’t willing to walk out on the field together and work with each other to win. And don’t make excuses to stop you from being as agile as you want to be…. sometimes I hear people say on (both on and off the XP mailing list) that they’d like to be agile, but their boss and customers pressure them to “just sit down and get it done!” Don’t make that excuse…. being agile is about being adaptable to change, the very definition of agile is “moving quickly and lightly with grace.” If you can’t move quickly, you’re not agile. It’s that simple.

SO, now that the ball is in your court, what do you do? Do you continue to make excuses and shove blame off on the organization, the boss, and your team members? Or do you step up and be a motivator for change, and motivate yourself and your teammates to hold each other accountable?

No tags

Been playing with jQuery at work today, and came across this excellent api documentation. Pretty helpful.

No tags

Recently while I was speaking with a fellow programmer, he was telling me how he wished that javascript had private methods/variables… sometimes it just felt so dirty just going on the honor system using “intended private” variables, i.e.

function Foo(){
    this._value = null;
}

I thought it was possible to have private variables and methods, and after some toying around I discovered I was right. The trick is to create local variables inside your “constructor”, then declare instance methods to access them (methods added to the object prototype can’t access them).

So, say we want a Person object who’s name is private, but provide getters/setters for it:

function Person(){
	var name;

	this.getName = function(){return name;}
	this.setName = function(n){name = n};
}
// EXAMPLE
var dude = new Person();
dude.setName('The Dude');
alert(dude.getName()); // prints "The Dude"

These methods are known as privileged methods… they can access private items and may be invoked publicly, however they may not be modified. Using the above defined object, if I do this:

var dude = new Person();
dude.setName = function(f){//.. some crud ...//}

Um.. nothing happens… calling dude.setName(“The Dude”); still uses the original. But out of curiosity, I added a method with the same name to the prototype and it still called the original. But the new method is there, how the hell do I call it!?

Person.prototype.setName = function(name){ alert("test");}
dude.setName('The Dude'); // calls the original method
Person.prototype.setName.call(dude, 'ffff'); // alerts "test"

Interesting, although haphazard. I think we will leave it at that.

Private methods work the same way… by declaring them as local variables in the “constructor” and then accessing them through instance methods declared there as well. Methods added to the prototype cannot access them.

So, to recap:

function House(r){
	var rooms = r;
	this.location = "downtown";
	var getNumberOfDoors = function(){
		return rooms*2; // each room has 2 doors.
	}
	this.information = function(){
		return "This house has " + rooms + " rooms and a total of " + getNumberOfDoors() + " doors.";
	}
}
House.prototype.getRooms = function(){
	return this.rooms;
}
House.prototype.getRooms2 = function(){
	return rooms;
}

var house = new House(5);
alert(house.information()); // prints "This house has 5 rooms and a total of 10 doors."
alert(house.location); // prints downtown
alert(house.getRooms()); // prints undefined
alert(house.rooms); // prints undefined
alert(house.getRooms2()); // breaks, no such variable

No tags

Recently during one of our project retrospectives, a colleague of mine noted one of the best practices I tried to adhere to was to use a timebox when I tried something out. The issue at hand was that we were writing acceptance tests for our project, and I wanted to write a fixture to generate links that had a specially encoded date time parameter. We both had different ideas, and my partner knew that I have a knack for sometimes going overboard when writing automated tests, which was also coupled with my partner’s inexperience with fixture writing that made him fearful of going along with my idea. So to ease his worries, I simply said “it’s 2:30 now. How about we just try it only for 10 minutes, and if we don’t have something useable by 2:40, we’ll try something else.” Luckily, we wound up with a simple, yet easy on the eyes FIT test without going over the timebox.

Although timeboxes are commonly used in XP when doing a SpikeSolution, I find it also useful when trying to get “buy in” with your partner when pair programming. Additionally, it helps keep you not only focused on the task at hand, but allows you the freedom to tinker without going overboard and wasting time. And once the timebox is up, and you didn’t complete your solution, turn the keyboard over to your partner and let them try their idea out.

Of course, a timebox is good for anything really… it underlies the urgency to do {insert whatever needs to be done here} within x amount of time, forcing you to focus only on the most important details while keeping the cruft to a minimum. This also why we try to limit our morning huddles to 15 minutes, to avoid turning it into a 1 hour meeting where someone goes into great depth and detail on an issue rather than just flat out saying “We were unable to do X because of Y”, in which someone can simply say “I have an idea on what we could do, lets pair up first session!”

No tags

During the closing session at the St. Louis Code Camp this Saturday, Brian Button wrote on one of the white boards “If you had fun, blog about it!” and jokingly added “But if you didn’t have fun, don’t blog about it.” Sorry Brian, but I have to admit… I didn’t have fun. Why? Because I didn’t win an XBox 360 or one of the Nintendo Wiis that were given away as door prizes. Other than that, I had a pretty good time.

To kick things off, the first session I attended Alex Miller gave a great presentation on Java 7. He covered a lot of the interesting features that “might” be in store for us, of which I found interesting NIO 2, the multitude of proposals for Closures, and Type annotations. Is it just me, or do some of the Closure proposals for Java range from simple and elegant, to slightly cluttered or outright ridiculous? Just keep it simple… I want to just be able to pass a code block in dynamically to be executed on demand, that is all. Anyhow, kudos to Alex for a very informative and eye opening presentation… it made me want to run out and download the jdk7. My question is, will Java 7 perhaps provide support for expanders? Only time will tell.

I also attended the Object Oriented Javascript presentation, which I admit I attended to get some ideas for a similar presentation I planning to give to some co-workers who may be interested. First off I would like to say that Adam Esterline did an AMAZING job giving this presentation on such short notice… I think Brian said the person originally scheduled to give it couldn’t make it, and Adam had about 30 minutes to prepare for it. It was a really great presentation on how to TDD javascript and write OO javascript using Prototype.

However, that is one thing I disliked about the talk, the use of Prototype. I think it’s useful, but I also think that people should learn the real object oriented syntax of a language before using scaffolding that waters it down and makes it different. I would have preferred to see something like this and this, but nevertheless it was a great presentation and I throughly enjoyed it, and no doubt will open the eyes of some people stuck in the days of writing many procedurally based javascript functions while cemented with the belief you can’t write object oriented javascript.

Throughout the day I got to chat up with a lot of other interesting developers on a multitude of topics, and really had a blast. Oh, and a few people asked me about you Cory, so I guess you made quite an impression at the code camp last year.

I can’t wait until the next code camp, and I must say that Brian Button deserves a special thanks for a job well done organizing this event!

No tags

There’s one important aspect of XP (and I think any agile software development process, if not any intelligent process) is to automate all tests. No ifs or buts about it. “But it can’t be done!” you say. Bullcrap. Anything can be automated if you try hard enough, and there are hundreds, if not thousands of tools out there to choose from.

“But, my customers won’t let me do that!”

Who are your customers to say you can’t write automated tests? What they SHOULD be concearned with is that you are delivering them a quality product in a timely matter. Quality being the keyword here… if you waste your development time manually testing the application (which can take quite a bit of time) you are already likely to miss a lot of different scenarios, and each time you need to retest, you’re going to spend the same amount of time manually testing it again… and again, you will probably miss something because let’s be honest, wouldn’t you rather be coding than manually testing stuff?

But then I’ll have to spend x amount of time writing tests, causing something that can be done in a day to be done in 3 days!

But if that extra time spent writing automated tests lets you test all of the scenarios in your application with the click of a button, is it really time wasted? If manually testing something takes 2 hours of your time, and you automate it so that you just click “test” and it does the same thing in even 5 minutes, and now you can repeat that test to your heart’s desire, isn’t that time well spent? If you can sit there and rerun your tests 10 times in 30 minutes, that’s possibly 20 hours of manual testing (which would never happen, so you won’t get the coverage).

The perception that it can take a lot more time to automate tests is concearning… because by automating tests we improve the quality of our product, and that improves our bottom line. So quit holding yourself down… quit thinking it can’t be done… and quit thinking that your customers won’t let you do it. Because all you need to do is tell your customer that you are doing this to ensure that they get top quality, and they’ll buy in.

Anyhow, some linkage to end this quick post.

Automating “All” Tests

No tags

This amused me quite a bit today: A Few Good Managers.

No tags