Posts Tagged‘methodology’

I’m More Agile Than I Thought.

I was a beautifully warm night in late December down in Jervis Bay. My friends and I had rented a holiday house for the New Years weekend and we had spent most of the day drinking and soaking in the sun, our professional lives a million miles away. We had been enjoying all manner of activities from annoying our significant others with 4 hour bouts of Magic: The Gathering to spending hours talking on whatever subject crossed our minds. Late into the evening, in a booze fueled conversation (only on my end, mind you), we got onto the subject of Agile development methodologies and almost instantly I jumped on the negative bandwagon, something that drew the ire of one my good mates.

You see I’m a fan of more traditional development methodologies, or at least what I thought were traditional ideas. You see I began my software development career back in 2004, 3 years after the Agile Manifesto was brought into existence. Many of the programming methodologies I was taught back then centered around iterative and incremental methods and using them in our projects seemed to fit the bill quite well. There was some talk of the newer agile methods but most of it was written off as being experimentation and my professional experience as a software developer mirrored this.

My viewpoint in that boozy conversation was that Agile methodologies were a house of cards, beautiful and seemingly robust if there’s no external factors on them. This hinged heavily on the idea that some of the core Agile ideals (scrum, pair programming and it’s inherit inability to document well) are detrimental in an environment with skilled programmers. The research done seems to support this however it also shows that there are significant benefits for average programmers, which you are more likely to encounter. I do consider myself to be a decently skilled programmer (how anyone can be called a programmer and still fail FizzBuzz is beyond me) which is probably why I saw Agile as being more of a detriment to my ability to write good code.

After taking a step back however, I realised I was more agile than I previously thought.

There are two methodologies I use when programming that are included in the Agile manifesto. The first of these is Extreme Programming which underpins the idea of “release early release often”, something I consider to be necessary to produce good working code. Even though I don’t announce it on this blog every time I get a new feature working I push it straight into product to see how it fairs in the real world. I also carry with me a copy of the latest iPhone client for testing in the wild to make sure the program will function as expected once its deployed. Whilst I don’t yet have any customers other than myself to get feedback from it still keeps me in the mindset of making sure whatever I produce is workable and viable.

The second is Feature Driven Development, a methodology I believe that goes hand in hand with Extreme Programming. I usually have a notepad filled with feature ideas sitting in front of me and when I get time to code I’ll pick one of them and set about getting it implemented. This helps in keeping me from being distracted from pursuing too many goals at once, making sure that they can all be completed within a certain time frame. Since I’m often coding on the weekends I’ll usually aim to get at least one feature implemented per weekend, accelerating towards multiple features per weekend as the project approaches maturity.

Whilst I haven’t yet formally conceded to my friend that Agile has its merits (you can take this post as such, Eamon ;)) after doing my research into what actually constitutes an Agile methodology I was surprised to find how much in common I shared with them. Since I’m only programming on my own at the moment many of the methods don’t apply but I can’t honestly say now that when I go about forming a team that I won’t consider using all of the Agile Manifesto to start off with. I still have my reservations about it for large scale solutions, but for startups and small teams I’m beginning to think it could be quite valuable. Heck it might even be the only viable solution for small scale enterprises.

Man I hate being wrong sometimes.

Form, Function and Methodology.

Conjure up in your mind a picture of the humble nail cutter (or if you have one handy grab it!). Not only is this device a marvel of modern technology it also proves to be a useful example of what good engineering practices should be. Can you figure them out? The same question was posited to one of my classes when I was still in university, and none of us could come up with a good enough reason to satisfy our lecturer. If you take a step back and look at a nail cutter you notice something, there’s not a lot to them.

The majority of nail cutters are made out of a grand total of about 6 parts (Lever, top cutter, bottom cutter, file, front pin and rear rivet). Whilst the whole thing might appear simple on the surface it is indeed a feat of complex engineering. Each of the pieces serves up more than one function in order to achieve the end result. Our lecturer at the time had us try to imagine a nail cutter that’s design only let each piece perform a single function. The resulting contraption was a monstrosity of dozens of parts and if created would have been more than double the size of a convention nail cutter. This exercise was done to teach us the importance of modularity, and when its gone too far.

One of the very first methods you’re taught as an engineer for problem solving is to take what looks like a large problem and divide it into smaller and smaller sections until it becomes managable. We were first taught this in reverse with our first assignments usually serving as a basis for the rest of the semester. However early in our second year we were given what appeared to be almost impossible projects only to have small clues as to their solution taught to us in the weeks ahead. The problem is however, that when you take the modular design methodology too far you end up with innumerable small components which then changes your problem into one of integration. The nail clipper example showed us that you shouldn’t modularize a problem beyond what will allow you to solve it, for want of introducing complexity rather than removing it.

You can see this methodology applied almost everywhere, for better and for worse. It’s one of those problem solving skills that doesn’t get taught in school and really its one skill that I can’t imagine myself being without. If you take the time to analyze any problem you might have and break it down into its basic components nearly anything just becomes a matter of time, rather than brainpower.

Now, go forth and modularize my minions! 😀