Source Control

I was just asked about source control by a friend that has only had experience in VSS. Thought I would share my rant:

Git (and other DVCSs) are a revolution in source control. They really are. Honest. I'll come back to why later but lets concentrate on what you know, VSS.

VSS has a very bad reputation nowadays. This is primarly because vss is known for corrupting its repository (http://www.codinghorror.com/blog/2006/08/source-control-anything-but-sourcesafe.html) but also because of its concurrency strategy, lock-unlock-modify

(http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.lock-unlock) which has gone out of fashion. Most VCSs (e.g. svc, cvs) use copy-modify-merge

(http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge) because this allows more developers to work on the same bit of code at the same time. This strategy is great but the risk is that you get problems when you merge. Obviously you get conflicts when you are merging in code into a different version of a file of the code you;ve checked out but some people keep whole versions of the codebase unmerged for extended periods of time. These can be versioned as well and are know as branches.

The rational behind branches is sensible. If you have major project N that is going to be being built for 6 months then you will want to a) keep it in source source control b) not have it messing up the code you are maintaining. So a 'branch' of the code is taken and you have the benefits of source control. the trouble comes when merging the branch back in quite often the code is so divergent that you have to do a lengthy and risk prone re-integration. (funny thing is that VSS has these integration problems too). Lot's of people more clever than me have struggled with this http://accurev.com/blog/2012/03/07/avoiding-merge-hell/ , http://martinfowler.com/bliki/SemanticConflict.html . Anyway the bottom line is that merging is hard in many vcs's.

The other issue with traditonal VCS's is that they make commits something you do rarely. In a normal VCS you commit to a repositroy only when you are finished. This goes against the meme 'commit early and often' http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html . Wouldn't it be great to create check points when you've finished a bit of code? Or if you just wanted to hide something somewhere? Also what happens if you want to share you codebase with 2 or more servers? Well in step DVCSs.

Distributed Version Control Systems such as Git, Mercurial (also known as hg) make the repository local. So you can have your own personal source control system on your own machine. This means you have all the benfits of a VCS locally. if your server goes down, you have the code. If you make a mistake, you can rollback. It's awsome and it promotes commit early and often. Git is even better because you can branch really easily and mor important merge really easily so all this merge hell that occurs with other systems is lessened (if you use it right). You can pull code in form as many sources as possible and push up to them and every thing. Git is so horrendously powerful that you can rewrite commit history, cherry pick commits. This is also dangerous too. (with great power come great responsibiltiy). It also means there's a crap load to learn. Also for windows you have to use a linux shell and the tools are best used on the command line. This also is a shock to windows devs. Luckily github has brought out a windows client that makes the experience more palatable. In short Git is much, much better than any other VCS I have used despite its learning curve.

i've not mentioned TFS. It's basically VSS next but with a CI server and an issue tracker built in. Its fukcing awful. Read this article and comments:

http://www.itwriting.com/blog/4744-real-world-microsoft-team-foundation-server-not-very-good-says-thoughtworks.html

I've used

VSS

SVN

Star team

TFS

HG

and Git in anger. SVN,HG and Git are the only ones I'd return too. SVN just looks like a dinosaur compared to the other 2.

Hope that helps.

Re: Over testing

It seems that one of the questions I asked on StackOverflow has gained some attention today, @dhh (of Ruby-on-Rails and 37Signals fame) mentioned it in a post on "over testing".

He's railed before against rspec and now he's being vocal about automated developer testing in general.
Whilst its great to question the status quo, I hope this doesn't signal a return to untested code.

Is the flock now going to consider testing as harmful?

DHH's post, in my opinon is actually very good but it doesn't cover new ground. Its been observed for some time that :

• TDD is not about just 'catching bugs'. 
• 100% Coverage is not pragmatic in 100% of cases.
• Code coverage is a metric that is fundamentally useless.
• Great swathes of tests are a maintenance headache.
• Writing testable code is a constraint on your design.

Before I got into writing automated tests I used to write a pseudo code comment, then write the code, then remove the comment. Then unit testing came a long and I began to automate that psuedo-code. Of course things take longer this way. Not only do you have to solve the difficult problem but you also have solve the difficult "getting things under test" problem. But here's where the power lies: By writing your intentions down you are forcing yourself to consider what you are doing. Its an extra step. Yeah there will be some rock star, alcohol drinking brogrammer who can write that code a billion times better than you without tests but even ninjas make mistakes sometimes. So I prefer to set up a test up front.

Now as time has progressed I find it more useful to write my expectations of what the stakeholders want. This means I think less about passing code and more about making features. TDD still has a place, a Behaviour Driven-style seems to fit better for me. Some of the BDD tooling I've used just was too much of an overhead in my situation, which is why our team dropped SpecFlow (a cucumber port) for MSpec (a cousin of RSpec). But we don't need to use any of those tools. It's entirely possible to do BDD with XUnit or anyother flavour of automated testing tools. It's just about OK to write tests after as long as you are clear what you are testing. (You wouldn't want to test the wrong thing.)

What the rise of TDD has given us though is a focus on quality, a return to craftsmanship. We don't want a return to shops thinking its ok to just sling code out and for their customers (or QA) to deal with the aftermath. There is of course a balance. I'm glad that people are beginning to question the practice. Over the last few weeks I've heard Dan North, Michael Feathers and now DHH push back but please don't stop testing.

Who is agile : a review.

I suprised myself last night in the reaction that I had to this book. I wasn't sure what to expect from the book but I'd seen a couple of tweets about it. So I fired up leanpub, chose my price and downloaded.

I loaded the pdf and flicked through the first few pages, skimming the contents, and reading a few further pages. The format is a standard set of questions, an extra question and a recommendation of who to interview. I flicked through the first interview with Lisa Crispin which was painless, relatively interesting,  but the questions were uninspiring (I'm guessing a generic questionairre is difficult to 'jazz up').

I then looked at the names down the list and thought about the format and felt little bit angry. Is this book an intropection of the circle that the authors know? What does it give to anyone else? What about all the people this book doesn't cover? Are they not agile?

So I have some reserverations. I had kind of thought this book would be a guide of how to be agile. I was wrong. Fortunately, so far, it's not so bad.

I probably know of, read, and respect 10ish of the 30 odd in the book. Some of the interviews I've read are fairly intesting but the power this book are the links that people mention. I've spent the last hour getting lost in the technical/agile and non technical books. The interviews are all light reading too. Something you can, by its nature pick up, read one and leave for a few weeks.

What I was pleased about was the communites section at the back. There's a ton of interesting information and ideas about things you can do in your community some stuff I hope to bring.

What I must remember is that this is a work in progress and it can be regenerated on demand. If agile is your thing or you are wondering if its more that just scrum & TDD then I'd certainly recommend you pick this up. If you are looking for another agile manual, there are better suited texts.

Looking forward to the updates and following the links.