So you have a development team, yet turn around on a product is slow? You have heard the words agile and scrum, but there must be more? Here are a couple of areas that a development team should work on to not only increase the turn around of a end product, but also increase the quality of said product.
Get your developers writing tests.. get your BA’s, QA’s writing tests… get everyone evolved, if you do it right, it will be fun… if you do it wrong you risk alienating people…
BA’s and QA’s are the people who see the 10,000 foot view of the system and the people who ultimately test said system – get them to write your feature files. But what are feature files? A feature file is the living documentation of a system writing based on the Gherkin language (https://github.com/cucumber/cucumber/wiki), the chances are that your BA’s have be writing something similar all along and didn't even know it… get them involved, and once they have completed a feature file, get a developer to implement it and demo the outcome to the business this way they will feel involved with the system, and make them feel like they have contributed to the code base.
Remember I said that feature files were the 10,000 foot view of the system? Well if the feature files works… then the system should too? right?
So now to developers.. Get them doing TDD – If you think that writing a test doubles your work load – you may initially be correct, but in the long run you are completely and utterly wrong. TDD will increase code quality if done right and decrease mistakes and debugging of developers (who really wants to be a debugging developer right?) – If I have a test, I hardly ever need to debug code anymore because I know what my tests are doing, and because I have a well driven out design the code is easy to read. So here is one big fact you will have more test code than actual implementation code in your system – what does this mean? It means that for one line of business logic written, there is usually about 10 lines of test code written – this is a good thing, not a bad thing.
TDD is a discipline – Its hard to start, its hard to sell, its highly addictive once you start.
Have you ever heard the saying that you should always cover your back? testing, using feature files and writing unit tests are the perfect way for a development team to cover their backs from the business. Stay safe I say and write a test first.
You cannot underestimate or put a price on a good continuous integration pipeline, because good ones are rare, require investment and are also PRICELESS – I'm going to reiterate this point good continuous integration pipelines are PRICELESS. A good pipeline is the difference between a fast turn around of code (a couple hours) to a slow turn around of the same piece of code (a couple of weeks – yes its true)
So what is the top notch pipeline? No one knows because I don’t think anyone is there yet. But these are some of the attributes of the best one I have seen…
1. Speed up compile time and test time – building through visual studio or other GUI is slow, so running a local task that compiles the entire solution, and runs all tests that are associated with the solution on the command line is quite essential – decrease compile and test time and you decrease over all roll out time.
2. A continuous integration and build management server picks up the check in to source control and runs the same task from step one. Remember a developers machine is usually full of crap (I should know), so make sure the continuous integrations server is as pure as possible.
3. One click deploys.. well this is something every team should be chomping at the bit to get, no one in their right mind would want to email MSIs or DLLs around to operations teams to deploy, this is 2011 not 1999… In fact it makes me mad even thinking about doing this. One click deploys are one of those milestones in a development teams history - imagine logging on to a build server, clicking one button, and all assets are automatically deployed out to a stage or live environment - Magic.
4. Automatically tagged deployments. One question people often wonder is what version of assets have been deployed to which environment? if you have a lot of environments this can get very confusing.. so when clicking that button that does the deployments, make sure that you have a process to tag that revision along with the servers, etc..
Continuous deployment is a huge milestone in a teams life cycle and should not be underestimated. If you want to buy off the business this is one of the big YES’s – a hard to sell, hard to implement procedure with a huge pay off. Have a read of http://www.avc.com/a_vc/2011/02/continuous-deployment.html which will help to not only sell it to your team, but to sell it to your business. Tests + CI = 4 minute bug fixes – Hooora!
This is different for every team, every developer, every manager etc.. everyone likes what they like, and getting it right is a pain. I have used Visual Source Safe 6, TFS, Mercurial, and GIT, and I have to say that at the moment distributed source control such as Mercurial or GIT are the clear winners.
I can understand that source control is a contentious issue and that TFS is the holy grail of some development teams., before we move on, put this in to perspective, TFS Costs around £1350 a licence, mercurial is free – Enough said.
Configuration… oh configuration, how I loath it and love it at the same time. Don’t get me wrong, configuration within a system is a good thing, it means you can change a system without having to change any code and do a recompile. So why do I loath it? Because pushing configuration to multiple servers can be a pain… and getting it right is in its very nature a pain! At Bath Spa university we used NAnt to xml poke values based on which button in the CI pipeline we pushed. At ITV we use yaml files which hold the configuration values within a type of hierarchy, the actual configuration files were then built at compile time. Very neat – yet still quite complicated.
If someone has a cool way to do configuration files based on servers etc, I would love to know!
Get a stage server that the business can see and roll out to it often. Companies often feel like development teams are like black holes, and that they only see their investment after weeks/months of development time. If you have a staging server the business can look at to see how progress is coming, this can help to reassure them that what they want are being delivered and hopefully reassure them that their investment is not being wasted.
If you have a CI Pipeline this should be easy to setup right?
How do I know I am doing this right?
So I have my Continuous Integration server, people are writing tests and I have some odd configuration gooey stuff that my developers are ensuring me is cutting edge, my clients love the fact that I am rolling out every 3 hours, so is this what you meant Nick? YES – and does it not feel good?
In my opinion if you do these steps, your time to deliver will be significantly decreased, after all is that not what we are all trying to strive for in the end?…