Agile Fail?

Slashdot has had links to When Agile Projects Go Bad at cio.com, and James Shore's post on The Decline and Fall of Agile this past week, and it's raised a couple of interesting points for me--mainly concerning the manner in which it is adopted in a business.

The CIO article opens with a piece describing how most people aquire new skills:

In the first stage, people need to follow a recipe. In the second stage, you say 'That's all very nice, but I need more,' so you go off and collect recipes and ideas and techniques. And in the final stage—if you ever get there—is a level of fluency and intuitiveness where you can't say what you're doing, but you kind of borrow and blend.

Introducing Agile as a methodology tend to lead to people in the beginning conforming to a checklist culture. The article then goes onto describe why this almost always has a negative impact on the process of building software.

Some people just assume that by incorporating the practices defined within a particular Agile methodology that makes their business agile. Anyone who has been within a team where this has happened can quite clearly say this is not the case: Weekly releases? Check. Pair programming? Check. Test driven development? Check. Requirements as stories? Check. How does going through the motions of applying these techniques lead to a better product?

Answer: it doesn't. I'm being quite absolute on this: if you're in a team that claims to be "agile" just because you are using some techniques you read in Extreme Programming Explained then think again.

Agile is a mindset you have to get into. It's about trust and professionalism. It's about seeing a problem as a series of stages, and tackling each one separately. It's about communicating with your team and customers constantly. It's about change.

It's not about processes, and yet the processes have become the poster children for the entire movement. Read the original Manifesto for Agile Software Development. Read the Principles behind the Agile Manifesto. There are no concrete techniques there at all.

These ideas are what Agile is about, but its abstract nature is proving to be its downfall. By being so abstract people bought in to the likes of XP and Scrum, where techniques were laid out. And it's always the techniques that are going to take precedence over ideas.

You can see that members of a team are pair programming. You can monitor the amount of tests that developers are writing. You can see requirements listed in story form. But how do you monitor Agile's ideas?

How do you tell if your team is motivated? How do you tell if you team is self-organised? How do you tell if your team is keeping a constant pace? These things are much harder to keep track of, but they stand at the heart of what pure Agile is about.

And it's this that leads some people to believe that Agile is a failure. In many ways it is, and I won't sit here and defend some implementations of it, but at its heart the set principles are sound.

But it's not for everyone. For Agile to make an impact you need a good team. A trusted team with experience and who aren't too jaded to try new things. A team that communicates, and where mistakes aren't chastised but taken in as just another problem to solve.

Communication and team work are key to making a success with Agile. It takes a good team to pull it off, I admit that. Some teams won't thrive under its ideals, but when you put the right people together it gives them all the help they need.

Just don't get too focused on the techniques you read about.

JQuery - How Javascript should be

I go for months without posting and then drop 2 in one night...

Let me first get something straight: I'm a focused lazy developer. If there's something already written that I can use to solve a problem I'll use it. As long as it's half decent and does what I need. But this has a flip side in that I code my own stuff with reusability in mind. Why spend hours solving a problem only to revisit it in another project a month down the line?

So I must say that for a long time I didn't really get Javascript. There didn't seem to be many opportunities for code reuse: each animation or validation check I did seemed wholly connected to one particular purpose. I struggled to generalise my solutions to enough of a degree so that they could be reused.

The impact of this was that I shied away from Javascript whenever I could: so when Microsoft came along with the AJAX Toolkit I was in heaven. Here was a collection of cool controls I could just drop onto a form and get a popup div, or a water mark on a text box, or a whole bunch of other stuff.

But at the back of my mind I couldn't help thinking this was all overkill. If I want a div to popup when I click a link, surely all I need is a CSS style on it, and swap the display style from javascript? So why have that as a control? Simplicity of implementation. It's easy. The lazy part of me liked that.

The focused part didn't. The focused part wanted to come up with a library that contained a load of these common functions so I didn't have to re-invent them on every project.

JQuery does just that, and more. I won't pollute the web with yet another JQuery tutorial (go see Rick Strahl if you want one) but I will say this. If you're a developer who likes to separate their concerns, take a look.

We're all familiar with layering applications: View-Model-Controller, Interface-Business-Data access-- it all amounts to the same thing. We're separating each element of the application so that we have structure. Structure eases maintainability. It removes bad smells. It increases orthogonality. For want of a better term--It Just Feels Right.

So why stick Javascript code in HTML? Isn't that polluting the structure of the document with behaviour?

Linking to a CSS file allows us to separate styling information from our HTML (or ASPX if you're into ASP.Net like me), and we all know you can link to Javascript files in the same way. If you're anything like I was though, all those Javascript files will contain is common "utility" functions. You'll still have "onclick" attributes in your HTML calling Javascript methods.

JQuery allows you to get rid of these onclick calls. Here's what I do:

• Have a JS file per page in your application
• Link to this JS file in your page as you normally link to script files
• Do not include any script in your page what so ever
  
• In the page's JS file, make use of the $(document).ready call to wire up your event handlers

For example: you have a floating div ("helpDiv") where you want to toggle the visibility based the click of a link ("lnkToggleHelp"). I used to add an onlick attribute to the anchor tag calling a Javascript function that would toggle the visibility.

In JQuery you can do this in your page's JS file:

$("#lnkToggleHelp").click(function(event){
event.preventDefault();
$("#helpDiv").toggle();
});

Which separates the behaviour of the page from the structure: leaving you with 3 separate but linked strands of a page: Style (CSS), Structure (HTML), and Behaviour (JS files incorporating JQuery). To me it's a whole lot neater.

That and all the effects and manipulation that you can do with JQuery means I can't see myself writing Javascript in the future without using JQuery.

Building a PC - easier than I thought

Last week I ordered a Shuttle G5 from icubes.co.uk along with a processor, memory, HDDs, and a DVDRW drive. I've never assembled a PC of my own before, but I've installed enough cards and memory to know enough about what makes one work--so I reckoned I knew enough to take the plunge and go for it.

And I must say it was relatively easy. There were a few stumbling blocks, like I'd ordered 2 SATA HDDs and a SATA DVDRW drive and the case only came with 1 SATA cable, but I salvaged cables from my old PC so I didn't have to take a trip to Maplins yesterday afternoon. Only other problem was smearing the thermal paste onto the processor. I've fitted procs once before but that came with a template that you stuck onto the bottom of the heatsink and filled. There wasn't anyhting like that so I just used a piece of an old business card that seemed flexible enough.

Must be working though because it hasn't over heated yet and its been on all day. Very quiet too, although my last PC sounded like a jet engine because of all the fans in it. I like the compactness of it too--it's smaller than the subwoofer that I had with my old PC.

I was going to post a step by step guide to how I assembled it, but there doesn't really seem to be much point. The case comes with instructions on what to plug in when, and if you've got all the cables you need you're fine.

Only things I would say if you've looking to do the same is:

• Make sure all the parts will fit into the chassis you're ordering
• Don't use too much thermal paste as it can go everywhere if you put too much on
• Buy extra SATA cables if you've chosen more than 1 SATA drive
• If you're not using IDE drives, you can take out the IDE cable to make room
• Your processor may come with a heatsink and fan, but the Shuttle includes one, so use it because it's quieter
• If you go with the G5 make sure you mount the DVD drive close enough to the front so the button opens the tray (you'll understand when you get there ;))

But apart from that, it's not too difficult. I wouldn't recommend it to an absolute novice as there's some things that aren't covered in the instructions, but if you know how PCs work you should be fine. And you'll end up with a pretty PC at the end of it.