Posts Tagged‘agile’

The Quest For Simplicity (or Who Pays For Rework).

I can remember sitting in one of my university lectures a long time ago being taught about development philosophies. It was all pretty standard stuff, we were walked through the “traditional” methods of development (basically the once through, waterfall technique) and then brought up to speed on the more modern iterative approaches. However one little soundbite always stuck out in my head and that was when the lecturer asked us who pays for rework when a product doesn’t fit a customer’s expectations? The simple answer was you, the one who developed it and it’s something that always plays over in my head when I’m working on a project, especially those ones I do at home.

I’ve been paying extensively for rework with my latest forays into the world of game development. My regular readers and Twitter followers would’ve noticed that I cheerfully announced my success in cracking the stable orbit problem. Indeed in a round about way I had, basically my Unity scripts would push the planet around until it hit a stable orbit and afterwards would calculate the required velocity before turning off completely, letting the heavenly body orbit in a near perfect circle around its star. This worked for the 2 planets I had in there but unfortunately the equations I had developed didn’t generalize very well and adding in planets at random locations with random weights led to all sorts of wobbly orbits with planets meeting both fiery deaths and cold extinctions at the cruel hand of my orbit stabilizer. I was back to square one and I spent most of the weekend trying to figure out a fix.

Eventually I came back around to the idea that my smart-ass subconscious came up with a while ago. I had tried to implement it before but I gave up in frustration when the results I got were no different than from my far more complicated “find the angle between the sun and body, increment it a bit, find the new position, create a vector to it then apply force in that direction” when in reality the fault lied in the orbit stabilization code. All that pushing and pulling that made the orbit look stable was in fact imparting all sorts of wild forces on the poor little planet, when in fact the best way is just to simply let gravity do the work for you. With this in mind I re-implemented my perpendicular force calculations and then devised a rudimentary equation that combined the mass, radius and a fudge factor that let me hand stabilize the orbit. In the past attempting to do this stuff manually took me an hour or so per planet, with this revised code I was able to do one in minutes and have developed a new equation that is able to accurately send a planet into a stable orbit no matter where I place it in the game.

This solution was far more simple and elegant than what I had been trying to do previously but the cost in terms of rework was tremendously high. I’m lucky in this respect in that the client for this is just myself and my friend at the moment but had this been for someone else with whom I had a contractual relationship with that kind of rework would’ve been extremely costly. Of course I could try to make the client pay for it but ask anyone who’s gone back to a client asking for more money after saying they could do it for a certain price and you’ll usually be laughed out of the office, if not walked out of there by security.

Working around this isn’t easy as clients will usually want to have a strict set of deliverables and time frames which seems to rule out any iterative or agile development methodology. It also pushes a team dangerously towards suffering from analysis paralysis as you agonize over every requirement to make sure it’s covered off in the final product. A healthy amount of analysis is good for any project, especially if it makes the product easy to maintain or modify, but it’s also incredibly easy to fall into a never ending spiral of pointlessness. Thankfully however I’ve noticed that clients are far more receptive to the idea of milestones these days which lines up well with any iterative process, skirting around these problems easily.

Going after the most simple and elegant solution might seem like the best idea at the time but in my experience it’s those kinds of solutions that take the longest to achieve. It’s almost always worth it, especially if all you’re spending is your own time, but when you’re working for someone else they might not be so keen for you to spend inordinate amounts of time chasing your white whale solution. This probably explains why a lot of software contains incomprehensible code riddled with bugs, but that’s a whole ‘nother ball game and a blog post for another day.

The Bullshit Behind “If It Failed, You Did It Wrong”.

I often find myself deconstructing stories and ideas to find out what the key factors were in their success or failure. It’s the engineer training in me that’s trying to find out what are key elements for something to swing one way or another hoping to apply (or remove) those traits from my own endeavors, hoping to emulate the success stories. It follows then that I spend a fair amount of my time looking introspectively, analyzing my own ideas and experiences to see how future plans line up against my set of criteria for possible future success. One of the patterns I’ve noticed from doing all this analysis is the prevalence of the idea that should you fail at something that automatically you’re the one who did something wrong and it wasn’t the idea that was at fault.

Take for instance Tim Ferriss author of two self help books, The 4 Hour Work Week and The 4 Hour Body, who has undoubtedly helped thousands of people achieve goals that they had never dreamed of attempting in the past. I’ve read both his books and whilst I believe there’s a lot of good stuff in there it’s also 50% horse shit, but that rule applies to any motivator or self help proprietor. One of the underpinnings of his latest book was the slow carb diet, aimed at shedding layers of fat and oodles of weight in extremely short periods of time. I haven’t tried it since it doesn’t line up with my current goals (I.E. gaining weight) but those who have and didn’t experience the results got hit back with this reply from the man himself:

The following will address 99%+ of confusion:

– If you have to ask, don’t eat it.
– If you haven’t had blood tests done, I don’t want to hear that the diet doesn’t work.
– If you aren’t measuring inches or haven’t measured bodyfat % with an accurate tool (BodPod, etc. and NOT bodyfat scales), I don’t want to hear that the diet doesn’t work.
– If you’re a woman and taking measurements within 10 days prior to menstruation (which I advise against in the book), I don’t want to hear about the lack of progress.

Whilst being a classic example of Wally Blocking¹ this also places all blame for failure on the end user, negating any possibility that the diet doesn’t work for everyone (and it really can’t, but that’s another story). However admitting that this diet isn’t for everyone would undermine it’s credibility and those who experienced failure would, sometimes rightly, put the failure on the process rather than themselves.

Motivators aren’t the only ones who outright deny that there’s a failure with their process, it’s also rife with the proponents of Agile development techniques. Whilst I might be coming around to some of the ideas since I found I was already using them its not uncommon to hear about those who’ve experimented Agile and haven’t had a great deal of success with it. The response from Agile experts is usually that you’re doing it wrong and that you’re inability to adhere strictly to the Agile process is what lead to your failure, not that agile might not be appropriate for your particular product or team. Of course this is a logical fallacy, akin to the no true Scotsman idea, and doing the research would show you that Agile isn’t appropriate everywhere with other methods producing great results

In the end it all boils down to the fact that not every process is perfect and can never be appropriate for any situation. Blaming the end user may maintain the illusion that your process is beyond reproach but realistically you will eventually have to face hard evidence that you can’t design a one size fits all solution, especially for anything that will be used by a large number of people. For those of you who have tried a “guaranteed to succeed” process like those I’ve described above and failed it would be worth your effort to see if the fault truly lies within you or the process simply wasn’t appropriate for what you were using it for, even if it was marketed to you as such.

¹I tried to find an online reference to this saying but can’t seem to find it anywhere. In essence Wally Blocking someone stems from the Wally character in Dilbert who actively avoids doing any work possible. One of his tactics is when asked to do some piece of work place an unnecessarily large prerequisite on getting the work done, usually on the person requesting it. This will usually result in either the person doing the work themselves or getting someone else to do it, thus Wally had blocked any potential work from coming his way.

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.