Code Slinging

iOS 5 upgrade issues

2011-10-13T13:29:00.000-06:00

I updated my iPhone 4 yesterday to iOS 5. I just wanted to say, what a frustrating experience. I first did a system update on my mac to get the latest iTunes. I synced my phone to get all the photos and recent purchases off of it. Then when iOS 5 became available I went ahead with the update. iTunes took a backup of my phone and away it went. iOS 5 downloaded without any issue and once complete I went ahead with updating my phone. It seemed to be proceeding without any problems, it wiped out my phone and attempted installing iOS 5. During the "Verifying restore with apple" stage it failed to connect to the apple update servers and it took a turn for the worse. It seems apple was unprepared for the number of people trying to update on day one and the update servers were timing out. Because the update had started, I was left with a blank iOS-less phone, basically a pretty black paperweight. It took several attempts over several hours to finally get iOS 5 installed but the fun didn't end there. Next was the restore of the backup that was taken just before the update process began. This too failed (with error -34). Several attempts seemed to solidify to me that the restore option was not going to work. Fortunately I had synced and imported everything before I began so I wasn't really worried about losing any data. My phone was in a usable state, it just wanted me to do some preliminary setup. So I went ahead with the setup but because it had only partially restored things all of my apps that were not bundled with the OS would crash. I had already set up iCloud on my Mac and so I decided to just set up the phone and re-sync it from iTunes. I had to reconfigure all my sync rules but after syncing everything seems to be working fine again. The only complaint so far is that it doesn't let me sync contacts,etc. with both iCloud and Google. I can see possible conflicts arising if trying to sync with multiple sources but it would be nice to have both...

A little frustrated and I still haven't had much time to appreciate having iOS 5. So far all I can say is the new notification centre is nice and I'm not yet convinced having music and videos separated into two separate apps is the better way to go.

Teacup Programming

2011-10-07T01:37:00.000-06:00

Teacup Programming is a variation on pair programming.

Why teacups? While sitting around a round table during a team retrospective where we had mentioned pair programming the conversation drifted a little when someone said it felt like we were sitting in a teacup ride or something. Naturally, this led to combining the two ideas and teacup programming was born.

The idea is based on amusement park rides where the rider spins a wheel in the centre of the ride to increase the spinning velocity of the rider's individual car. The most widely known example of this is the Teacup ride at Disneyland.

Requirements

An even number of programmers
a table (round is preferred but not necessary and a rotating table is even better)
one computer for every two programmers

Steps

1. Sit the programmers around the table with a computer in front of every other programmer.

table setup

2. Each programmer with a computer begins working with the programmer on his or her right.

pairs with person to the right

3. After a designated period of time, say 30 minutes, the pairs switch. This is done by either rotating the table one spot to the right or having everyone move left one spot so the programmer on the right from each previous pair is now sitting in front of a computer.

rotate the table one spot

after rotation

4. Again, each programmer with a computer then begins pairing with the programmer on their right (this is a consistent rule for creating pairs) and the timer is reset for another 30 minutes.

again pair with person to the right

5. Goto 3.

The key point in this rotation system is to always have the one programmer from a previous pair remain working on the same computer and thus on the same problem to help reduce lost time due to context switching. Also, everyone at the table gets a look at each problem which means more eyes looking at the code. The drawback is that one programmer only ever works with two others at most.

Variant

programmers "leap-frog"

A variation to increase the number of pairing combinations is to have the person relinquishing control of a computer get up and "leap frog" positions one direction or another. This adds more complication to the rotations but allows an individual to pair with more people in the group.

We have yet to actually try this out and so cannot say whether it is a viable technique or not but I think it does have some merit and there may even be some specific situations where it might be best applied such as at a hack-a-thon where there is a long list of problems or bugs trying to be solved none of which are too lengthy or difficult or for practicing for a programming contest where people are just trying to solve as many problems as possible.

If anyone gets around to actually attempting this please post a comment with the results.

Remaking the bed...

2011-10-07T00:19:00.000-06:00

I follow @unclebobmartin on twitter and was also getting caught up with his blog posts and have been enjoying his rant-like video posts. I particularly liked this one about Architecture Deference and even tweeted saying so. I found it to be a good pre-cursor to this post on Screaming Architecture which I'm sure came partly as a result of the first.

I've been dealing with issues in some of our apps and haven't been able to put my finger on where they stem from and these posts really seemed to highlight for me what it likely was in the approach that caused these issues. From the running of tests taking too long to too much focus on the aspects that don't really matter and should be deferred, I think I know where many of the issues lie. The only problem now is figuring out how to fix it once it's been done... or is it too late? Would it be too much to decouple the model, or the architecture, from the frameworks and tools to make it not worth the effort? Do we just say lesson learned and take a more correct approach the next time around?

How tired am I? Do I just want to go to sleep in the bed that's made or do I remake it? Can it be remade?

Making Mock Data Fun

2011-01-21T10:36:00.000-07:00

While looking at documention for Pivotal Tracker's Activity Web Hook we were looking at the following piece of XML they provide as sample data:

<?xml version="1.0" encoding="UTF-8"?>

<event_type>story_update</event_type>

<occurred_at type="datetime">2009/12/14 14:12:09 PST</occurred_at>

<author>James Kirk</author>

<project_id type="integer">26</project_id>

<description>James Kirk accepted "More power to shields"</description>

<story>

<url>https:///projects/26/stories/109</url>

<accepted_at type="datetime">2009/12/14 22:12:09 UTC</accepted_at>

<current_state>accepted</current_state>

</story>

</stories>

</activity>

They also show the following example for creating a new user:

e.g. Name, email, or James T. Kirk (JTK) <kirk@starfleet.edu>

We couldn't help but laugh and think that pivotal must be a fun place to work. While discussing other types of funny mock data we'd seen both in our own office and elsewhere we had the thought that having fun mock data could help get developers more involved with testing.

In my experience most developers dislike creating data to test with. I'm not talking about making mock objects but making actual test data that mirrors what you'd expect to have in a real system. It's tedious and not very fun. Nothing beats real data of course, however, a good set of mock data makes it much easier to test an application either manually or in some automated CI system so it is definitely something you want to have when developing an application.

Switching to PivotalTracker

2010-07-06T12:45:00.000-06:00

For our SCRUM development we have used a variety of tools to plan and track our work.

Mingle
We used Mingle for a long time but found that because it is so customizable it makes it very easy to overcomplicate your project and process. We also spent a large amount of time configuring, setting up and tweaking mingle to create the ideal project template. Mingle is also very slow and seems to require a server with a huge amount of resources to run smoothly.

Scrum Ninja
Scrum Ninja has a lot of nice features and seems to be going in the right direction but it was very glitchy and we even lost some data at one point. We were able to get most of it back through their support but it was definitely a hassle. Searching didn't work very well and although the card wall view is a nice idea it can be hard to read. The export format is relatively useless leaving out important data like dates. It wasn't even worth trying to parse the exported text with a script to extract what we wanted.

Pivotal Tracker
Pivotal has done a very nice job with their Tracker product. We first tried at the same time as ScrumNinja and first impressions left us feeling it was more restricted or had fewer features in some areas. We gave it another go and now realize it has a much simpler interface that we've found frees us up to just work on the project rather than spending time setting it up in the tool. It has several integrations with other projects and an open API for custom integrations. We've also made suggestions and bug reports and had very quick responses and fixes. It also uses csv as an export format. All in all we're very happy with Tracker so far. Plus, it's free.

overcomplicating things with the repository pattern

2010-07-06T11:47:00.000-06:00

The Repository pattern was used in a project by some team members 6 or so months ago and it's being mentioned again along with concepts of an Aggregate Root in discussions on refactoring another project. Both of these projects were C# projects using LINQ to SQL. While working on the first project I kept thinking that the repository pattern seemed to just over complicate things and I couldn't see what real benefit it brought to a fairly simple application. Now, I've done some further reading on Aggregate Roots and found ties to the repository pattern again. As I read through several definitions I kept thinking that the main benefits are already provided via LINQ and implementing it on top seemed to only add another abstraction layer. I did some more searching on the subject and found this article: Repository is the new Singleton and it just echoed everything I was thinking.

Creating a repository for data that is already in your DB is overkill when you are using LINQ (and likely any modern ORM) for accessing that data since the data access provided by LINQ is itself making use of the repository pattern . A good place where the repository pattern would be useful is where you may have different sources of data.

Here is another interesting article about the Purpose of the Repository Pattern that talks about some of the issues when using this pattern along with LINQ. The DataContext issues he mentions exist generally in a Web Application built on LINQ and not just when using repositories. Our team got around some of the DataContext issues by using a DataContext Factory that we found that creates a scoped DataContext within the HttpContext and while within the scope of the HttpContext it always returns the same DataContext. This helps keep anything within the HttpRequest in the same Unit of Work. It was also written to work within the current thread if a HttpRequest is not available (a non-web app).

Is the industry moving away from Agile?

2010-02-09T11:31:00.000-07:00

I don't think so.

I'm writing this in response to a link to this article on slashdot that a friend sent me asking the question which I've used as the title for this post. (The slashdot article references this blog post which is a good and informative read in itself and I found I agreed with many of his points. What starts as an emotional rant turns into a very well presented article.)

There isn't just one way of doing development or just one way of doing agile; hence the name agile. I thought the first poster on slashdot hit it on the head especially with his comments about having the right people and making adaptations to your business.

The author leads into the article complaining about agile but later talks about how many other methodologies can also be successful. The important thing in my mind is picking the right approach for the job (or team even; some methodologies only work with a certain type of people) and also understanding that methodology properly. In fact, the understanding must come first to be sure that you do pick the right approach for your team/project.

The author made a good point about how some people use the words "agile" and "scrum" interchangeably. It is my opinion that these are the teams that fail at agile. It could be that some see agile as being less structured and as a result end up thinking there are fewer rules and less accountability. An agile approach may give the developers more leeway and freedom but with that comes more responsibility. My experience has shown that a junior team usually cannot succeed in these circumstances. They typically will not have the experience required to make the design and implementation decisions that are usually made by someone else in a different model. It's been a challenge to overcome with some of our teams.

We use SCRUM outwardly but also take the XP approach mentioned by Kent Beck in "Extreme Programming Explained" and implement changes slowly. We reflect each week in our sprint retrospective on how those changes helped/hindered us and we also talk about new ideas and ways to improve our process. Yes, we follow a scrum model but one that we have adapted to our needs. We also know that it is more than just doing this list of things and then we'll have it right. We know that the business needs change, the business itself changes and that we need to be able to change and adapt in order to keep pace. I feel that with the right mix of people and support from management agile can be very effective.

Although we don't do game development where I work, I had previously found this pdf about lessons learned implementing SCRUM at Bioware and one of the key things I took from that was that they also ended up adapting SCRUM to their own needs. I think this is key to success with any methodology; being able to take what works and adapt where you need to.

Setting up TortoiseGit to work with SSH on a different port (not port 22)

2010-01-21T13:51:00.000-07:00

So recently we've had some headaches giving users on Windows machines access to our git repository (me being one of them but not the first). In searching for a solution to this problem I found several people with the same issue but having to use various workarounds or actually change their ssh port back to 22. All of the workarounds were out of the question for me but I knew there had to be a way to do it. Basically I just followed some of the better posts about using Git on Windows out there with a couple minor changes.

Here are links to a few of the posts I looked at while trying to figure this out:

http://www.lostechies.com/blogs/jason_meridth/archive/2009/06/01/git-for-windows-developers-git-series-part-1.aspx

http://nathanj.github.com/gitguide/tour.html

http://kylecordes.com/2008/04/30/git-windows-go/

The important pieces to make sure you get it working are these:

Be sure you choose the OpenSSH option when installing msysgit
Be sure you choose the OpenSSH option when installing TortoiseGit
create a .ssh/config file and enter something like the following

Host name_of_host_where_your_git_repo_is

User git

Hostname name_of_host_where_your_git_repo_is

Port port_number

PreferredAuthentications publickey

IdentityFile "/path/to/your/openssh/private/key"

And you should be good to go. I actually set up msysgit and my ssh config file first, then I made sure that I could connect and then I installed TortoiseGit.

Tips:

If you created your private key using puttygen then you'll need to export it (using puttygen) as an OpenSSH key.
While testing your connection you can use ssh -v git@github.com (or @ your own host even) to see what ssh is doing and to make sure it is finding your key correctly.
If your openssh key is located at C:\users\myuser\keys\key.ssh then the path to your IdentityFile should be like this: /c/users/myuser/keys/key.ssh

SQL Server 2008 express

2009-10-09T14:11:00.000-06:00

I spent the better part of today attempting to get my (Windows Vista Business :/ ) system to a state where I was able to run the installer for SQL Server Management Studio 2008 so that I could access a 2008 sqlexpress instance running on another machine. It's finally running the installer as I type this and the annoying thing is that my friend was able to access the DB using RazorSQL (usign the jtds driver) on his Mac without a problem. It's infuriating that I have to go through all this hassle when I could have just used a non-Microsoft tool to do the job. I don't see why SQL Server Management Studio 2005 can't access the database at the same level as jtds. I suppose if I added an odbc connection on my computer to the db then I could have accessed it that way...

The install is now finished... Hopefully I can at least get some work done now.

Errors with an Upgraded Rails version

2009-09-29T15:03:00.000-06:00

NameError: uninitialized constant ApplicationController

I've had to take a shelved project written for rails 2.1.1 and try to get it running again and ran into an issue getting it to work with the version I have on my machine; namely rails 2.3.4. Thanks to this post I was able to quickly overcome the most obscure error rather quickly.

Team City's FxCop Runner

2009-07-07T13:15:00.000-06:00

Team City has a number of built in runners to use on your project that provide some pretty nice reports right within Team City. Some of those we're using are the Duplicates Finder (.Net) and the FxCop runner. The Duplicates was pretty easy to set up but I had a little more difficulty with FxCop. Nothing serious but I thought I'd reproduce what we did here.

First, of course, we had to make sure that FxCop was installed on our Build Agents. Then I added the following to the buildAgent.properties file

system.FxCopRoot=c\:\\Program Files (x86)\\Microsoft FxCop 1.36

Make sure to escape the colon and backslashes.

Then I had to create an artifact from my compile build configuration that was the bin folder containing the assemblies I wanted FxCop to look at.

Then I had to create an artifact dependency on that artifact in the FxCop build configuration; otherwise there were not any assemblies available for FxCop to operate on.

That did the trick for me.

The next step is to create a Dashboard type page that will have a script that will grab all the different metrics created from FxCop, Duplicate Detection, NCover, our burndown chart, etc. and display them in easy to view way (graphs and what not). We'd have all developers set this to be their home page (or ideally have it displayed on a wall somewhere) so all this can be viewed at a glance and you can get a quick overview of the project. I think this will be really valuable as a tool while trying to take TDD to the next step.

Continuous Integration Wash Cycle

2009-05-07T12:20:00.000-06:00

This post about a developer's daily routine when using Continuous Integration is a nice breakdown that can be used when introducing people to CI. Following the links through the posts brings you eventually to this post about Discontinuous Integration which reinforces the practice of committing often. Following a daily routine as described in the first post will help prevent discontinuous integration. We've switched to using Team City after having used both CruiseControl.Net and Cruise for our CI. Team City is by far the most usable and makes following a daily routine much easier.

TDD in MVC applications

2009-03-25T06:42:00.000-06:00

When developing a web application using MVC there are some components of the application that are not easily tested and can't be tested using automated unit tests. Since automated unit tests are the TDD bread and butter it follows that you can't use Test Driven Development for every aspect of your application. Our team has mentioned that it is difficult to know when to use TDD so I'm hoping to provide some guidance to help in this area. Any comments or suggestions about other methods are welcome.

Libraries: "That code should be in the Model!"

I think it's pretty simple really. Basically anything that will be used as a library function should have a unit test written for it and anything that should have a unit test written could be developed using TDD. In MVC, you would use TDD to develop Model code. If there is any code in the controller that contains some business logic that could be pulled out and made into a library function then that code should be in the model.

Any other aspect of the application would need to be tested using acceptance testing methods.

Are You Invested?

2009-03-23T23:44:00.001-06:00

We use Scrum and have weekly sprints. I had someone asking me about a piece of the application that had been developed in a sprint a couple weeks prior. The developer asking the question had not worked on that piece during that previous sprint and was now working on something that involved refactoring a portion of that code. During the discussion, when asked about how certain pieces of it worked, the developer brought up the fact that the piece of code was not written by him, as if to say, "Well, that's not MY piece of code". I was more than a little surprised by this comment and not only because in Agile development there is collective code ownership but also because it shows a lack of investment in the project. These obviously go hand in hand. The more invested a developer feels in a project the greater his sense of ownership.

Even so, the concept of collective code ownership means that all team members are responsible for the code that is developed. That doesn't mean that you have to know every detail about the application or about what your team members are working on but it does mean that you should at least know what they are working on and how it impacts the rest of the application. If they are applying a new technology you should at the very least have an idea of some of the issues that can come up while doing so simply from the daily stand up meetings. The point of collective code ownership is that any member of the team can work on any piece of it. A single piece of the code is not dependant on a single developer. This is also a benefit of occasional pair programming and having other team members test your code/tasks because it allows for another pair of eyes to look at the problem even if it is done as more of an overview.

So if a developer comes across a task that requires them to work on a piece of the code that they haven't worked on before they should be doing all they can to learn what they can about this piece of code. Whether they turn around and talk to the developer who first wrote it, read through the code (which would probably be my first step) or start researching on their own by looking online, in books or other documentation, they should be invested enough that the fact that they did not write it in the first place should never even come up.

TDD Adoption

2009-03-20T01:08:00.000-06:00

I've been doing a lot of reading about Test Driven Development and how to use and apply it and found some of the most revealing material while reading about Behaviour Driven Development. I was reading this Introduction to BDD and the TDD Adoption Profile mentioned at the top of the article was the catalyst for this post. This will make sense to anyone who knows anything about BDD since BDD is basically an attempt to relabel TDD to help people use it more appropriately.

What I hope to do here is highlight some of the key areas that seem to cause developers to fail while using TDD or fail to adopt TDD. I get the impression that development teams attempting TDD often end up not using it properly or consistently or else quitting.

Developer Buy In

This could be a failing point of any development technique but I think it affects TDD more so because of the requirement to write tests first. If the developers don't buy in, they won't write tests and will continue to just develop in whatever way they are accustomed to.

Focus on Testing

Of course there is a focus on testing in TDD! The T stands for Test, doesn't it? This was one of the biggest realizations for me while reading the BDD Introduction mentioned above. They mentioned that most developers get to step 4 in the TDD adoption profile and stop there missing the benefits of steps 5-7. I think this was a big realization for me since I was probably still at step 4 in my own acceptance of TDD. After reading steps 5, 6 and 7 and reading about how BDD is basically TDD with less focus on testing and instead a focus on behaviour I began to see the real benefits of TDD. So to oversimplify things, the BDD folks are basically rebranding TDD to focus attention where the the real gains in TDD can be made. This leads me to wonder then if a developer would gain more by first being taught about TDD with this emphasis in mind rather than having to get there on his own, making these realizations as he goes. I can see how the personal realizations would carry more weight than just being told about these things in advance but wouldn't foreknowledge at least increase the likelihood of the realizations occurring?

Learning TDD on the Wrong Project
I don't mean to suggest that TDD only works with certain types of projects but I'm convinced that there will be a greater chance of adoption if the selected project is a new one or has had very little work done on it. The reason I say this is because the first step in TDD is to write tests first and not to write code you don't have to. So writing tests for existing code can at times seem pointless or at least more work than it's worth when you already have a working application (although there is merit in having thorough unit test coverage) and writing tests for new code requires the team to develop using new techniques on an application they've likely already spent a lot of time on and are fairly adept at debugging. I'm not suggesting Unit tests shouldn't be written or that TDD can't be used on an existing project, I'm just pointing out areas where I have seen resistance to TDD adoption. For a team new to TDD it may be better to start fresh. Starting fresh may also help the team feel more inclined to experiment with this new method whereas an existing project will already have set expectations the team is accustomed to. I appreciate that step 1 in the TDD adoption profile is about starting by writing unit tests around their code so perhaps a first foray into TDD is best done on an existing project but I would argue that it would be better to not refer to it as TDD at this point in time because it is actually not yet TDD. Instead I would call it what it is and that is writing unit tests to help improve the quality of the code being tested. It is not yet TDD because TDD requires that you first add a test for the feature you want to add and then after seeing the test fail you implement the feature.

Poorly Designed Code is Hard to Test

One of the realizations while learning TDD occurs when the developer discovers that TDD is in fact a design process that helps them define the application's API. Developing in this way will likely produce better code than was previously being produced and of course have tests written for but my point here is that if attention is also given to applying best practices like proper object oriented techniques and design patterns then TDD adoption is smoother and the TDD process itself becomes easier. Take MVC for example. When followed correctly all business logic should end up in the Model which makes things much easier to test, especially if the model was created using object oriented design principles.

I know some of what I've said are problems that are addressed by using TDD and in realizing that it hopefully increases the value of TDD in the eyes of those trying to use it.

Kent Beck has written a great book called Test-Driven Development: by Example that I would recommend as a great starting point for anyone trying to learn TDD.

Some might ask, why not just use BDD? My response at this point would be, I don't know, why not? Perhaps frameworks for BDD are not yet as established as those used in TDD. Maybe we should all switch to BDD. Or maybe, TDD works just fine provided we shed light on more than just the testing aspect of it.

Design Patterns vs. Architectural Patterns

2009-03-04T01:38:00.000-07:00

After discussing MVC and it's use (or non-use, actually) in some of our apps it became apparent that a bigger problem existed in the design of these applications. Now most of our apps are used in house and were developed initially by a group of bygone developers and as part of the ongoing task of trying to enhance and adapt them we are reminded of the benefits of a strong attention and adherence to good design.

Despite being written in an Object Oriented language, much of the functionality in these applications is accessed through static methods and the model classes are nothing more than containers. When model objects tend to be simple containers we get this confusion about what the controller actually is. If all appropriate code were actually in the model classes the division would be a little clearer. LINQ makes things a little easier because it creates a bunch of your model for you and you can build on it using partial classes and such. The problem persists in LINQ apps though where if developers don't follw good OO design we can have all these static methods adding another layer of complexity to everything.

There is an article on implementing MVC in ASP.Net that outlines it pretty well. The part I don't like is that the model is not object oriented but uses static methods. It is still a good reference though. So in the context of ASP.NET, the way I see it is that the code behind is the controller and basically everything else that is not an aspx page is the model.

Both Design Patterns and Architectural Patterns will improve the quality of code when applied. It follows that using them together will yield even better results.

Subversion Best Practices: Branching and Merging (because we've been doing it wrong all along)

2009-03-04T00:45:00.001-07:00

Despite having read the chapter on branching and merging in the svn book, and spent a lot of time thinking about how it should be done, the subversion repository structure at both my current job as well as my previous one have left something to be desired. Branching and Merging never quite worked as nicely or smoothly as it was supposed to. Eventually we just looked at how the Apache project did it and the correct method became clear to us and although we are not suggesting exactly what they're doing (they have active development happening in several branches) it took looking at their project to make the light go on.

The Old Way

Trunk was supposed to mirror what was in production, although we were never actually able to achieve this which sparked the many discussions about how else we could do it.
All Development happened in a numbered branch and a new branch was created for development every time we wanted to push to testing in preparation for staging (which made for messy SVN logs and much difficulty with Merging caused by confusing ancestry).
Bug fixes would be made to the old development branch which would then require us to either make the same bug fix to the new branch or merge the old branch up and then back down into the new branch or even a merge directly across between the 2 branches, all of which added to the mess in some way causing conflicts or ambiguous ancestry.
Tags were made when something was pushed to staging/production but it was unclear how/when these tags should be created.
It was confusing to explain the branching procedures to new people and difficult to enforce/maintain.

The New Way

Development occurs in the trunk. Trunk is ultimately the development branch itself. The majority of development will occur in the trunk.
Branching occurs when:
1. We want to create a release of current feature set. This can be done as a Tag, or a branch and a Tag. The latter method would create a branch for doing bug fixes and new tags would need to be created for that branch every time a set of bug fixes are pushed as a release.
2. Development of a new feature would seriously disrupt normal development
Release branches will be pushed to Testing, then to Staging and finally production. Bug fixes to these branches will be done within the branch and then merged up into the trunk. This way bug fixes are always included in the trunk (dev) and there is no messy merging across or down from trunk into a current dev branch.
Every set of fixes/changes made to the old branch are tagged so we know which version contains which set of fixes.
Easy to explain to new people.
Easy to maintain.

Code Slinging

2009-03-04T00:07:00.001-07:00

I've thought for a while that I should start a development related blog where I can drop bits of development related goodness. The name Code Slinging came to me while reading the Contrasted with "cowboy coding" section in the wikipedia article on Agile Software Development. It was the first time I'd heard the term but thought it very apt and it prompted me to go ahead with creating this blog.

The interesting thing is that anyone who has ever written code would more or less have had experience with the Cowboy Coding methodology, if we can really call it a methodology since it lacks structured methods and procedures.

Like I said, it was the first time I had heard the term but as I read it's definition it all seemed very reminiscent of anything I had done on my own or even most group work while at university. The initial reaction is that it has a negative connotation (especially after having worked on an agile team for the past year and on a modified RUP team previous to that) but on further thought I can see merit in actually choosing it as a development methodology in certain circumstances. These circumstance, rare as they may be, would require a small, skilled team of individuals who trust one another and their abilities and who have near complete autonomy in the decision making process. However, I think these circumstances are so rare and the conditions for successful execution so difficult to achieve that it renders Cowboy Coding a viable option only when the decision maker is the sole developer on a project. Basically one man jobs or personal projects.

Cowboy Coding can in many cases very much resemble agile methods because they both have working software as a measure of success, they are both adaptive methods and they both require trust between developers (to be successful). However, without a focus on some integral agile principles (like specific timeblocks that are in themselves complete development cycles) it cannot be classified as such.