What's required for an efficient development team?

Running an efficient development team is not an easy task – but many people, especially managers, seem to think its just the same as running any group of people.

And so it is – but whomever is responsible for the dev team needs to be technical. They’ll be the one that has the responsibility (and authority) to make sweeping architectural changes on active projects when problems are encountered. If companies put non-technical people in these rolls, you rapidly end up in a cycle of meeting after meeting discussing things, with nothing ever being done.

But there is more to it that a good manager; many people in the industry will have heard of the Joel Test – this is a short, simple test that Joel Spolsky came up with back in 2000, but is still very relevant today. It highlights that there are key areas that will significantly impact on your dev team, and ultimately potentially change the outcome of any projects (poorly run dev teams burn more time “freewheeling” rather than working). Why not have a read of the FogCreek About page (that’s Joel’s company in case you were wondering) – now that’s a company that a developer would be happy working for!

I’ve been in and out of enough software companies while consulting to pickup on common issues, and it truly is startling how often the really basic points get missed – time and time again. So often, I’ve actually ended up with my own checklist of things to watch out for:

Planning, Scheduling and Change Management

Having a good understanding of what you are trying to do is … well … important. And yet so many (significant) development projects start with no regard to what is actually the aim.
At a minimum you should understand:
* The problem you are solving
* The target audience
* How they will use your package (Use cases!)
These in turn should lead to a functional and testing specification – without these, you can’t plan …
Then you should actually plan your releases; agile is good here, as you force yourself into short, manageable release cycles – and this in turn forces you to keep to small working units. As a rule of thumb, break your functions down into tasks, right down to the hours to implement level (this forces you to do the technical design work you see!), and record the information in your planning software. Be sure to allow time for planning, development, bugs etc.
Once your development cycle is underway, you shouldn’t change anything within it – any time you change what is planned in the active cycle, you risk completely blowing it out the water.
Every day should start with a quick (max 5 / 10 minutes) development meeting, involving ALL your development staff – at this point daily requirements are outlined (based on the current release plan – remember, no changes!), and potential problems are brought up – if there is anything that needs to be discussed in detail, this should be handled separately. This format allows for a good understanding by all of the big picture; without this information they might feel not only devalued, but also question what it is they are working towards.
Before the start of a development cycle, a planning meeting (or more than one!) is needed; normally this starts off being project stakeholders and technical lead only, but eventually includes the developers once a time estimating point is reached; it should always be the developers themselves that complete the actual time estimates.
At the end of the development phase, a comprehensive testing and signoff stage should begin; where requirements are checked and the project stakeholder is notified. At this point, release management takes over.

Source Control

Source Control really is a simple step. And I don’t mean a simple source control system; I mean something that can handle Branch and Merge operations – properly. No matter which way you run your dev team, you WILL end up with multiple copies of one project alive (release and development anyone?) – and far too many places work using “copies” of the code, and manually sync changes. Far too painful, so inefficient and so error prone!
Then we get onto the problem of single locking. If you run a very basic source system, with single locking in place you will possibly hit problems – especially if your developers have a tendency to not check files in regularly (but more on that later).
Under no circumstances should you EVER have a project where the code lives on a developers machine, and is not source controlled.

Automated Builds

Continuous integration and automated builds might not fit your project, but just how are you building your release editions now? I bet they are probably done by a developer, on a developers machine manually? So how can you be sure there are no strange dependency problems (missing files!), or incorrect versions (DLL Hell), or even a virus or two creeping into your release? Or even, how can you be sure you are not about to release a debug config file? You can’t.
We all make mistakes, especially when under pressure – don’t put your project, or even your company at risk by not having the ability to generate a release drop (fully unit tested) at a single click.

Support and … Bugs

These are two topics that people quite often treat incorrectly in my opinion.

Support is just that. Support. Helping users, and identifying issues with products. When they encounter a problem with the product that is reproducible, it should be transferred to the technical lead for evaluation, and recorded in the BUG tracker. The eagle eyed among you might have noticed I specifically said bug tracker. Yes, there should be two trackers – if you run a tracker for support that is. Support and bugs MUST be kept separate – you will want your developers to record detailed information against bugs, and manage them (linked to source changes etc naturally), whereas support personnel shouldn’t have to wade through all this information just to find out when it was fixed.
Not to mention that most support people (and customers) don’t know how to create a good bug report anyway; because of this, a technical lead should always evaluate the bugs before they progress – if only for technical accuracy!

Environment

Working environment really is key to development. Some people prefer quite areas, some people like background noise. One thing that everyone agrees is bad is loud noises, or lots of conversations or commotion. These break concentration, and will ultimately drive your devs nuts. Break out areas, and meeting rooms should be used for any significant communication / collaboration – not the middle of the office.
Companies shouldn’t be too strict on preventing people from customising their workspace either – as long as it doesn't go overboard of course! I personally like having a picture of my motorbike around …
Bosses also need to realise that software development is not a 9 to 5, at your desk throughout proposition. We often get problems that we encounter that we just can’t break – and we need to get out of the office, get some fresh air, some peace and quiet. But it’s not that we are bunking off – we are getting away to THINK about the problem at hand. Obviously this is really difficult to police, but if you trust your development team, allowing them flexibility like this can massively increase productivity by allowing them to fully think through and design good solutions to problems.

Training

Always a sticky subject this one; but companies must realise they need to work with developers to keep their skills current – developers hate being out of date (usually!), and if a company keeps them trained they will in return be more loyal.
That, and the last thing you want is developers who can’t use the tooling that they have optimally – if someone can not use a merge tool, they will resort to merging files by hand which costs you (the owner!) money!

 

When I submit a report on a dev team, with suggestions on how to improve their work flow, the most common response I get is “it’ll cost too much”. And almost every time, they are not thinking about things logically – specifically, what are the costs that are occurring now through the poor practices? Bear in mind they might not all be quantifiable now as it can even be things like customer confidence.

Most places that are carrying out development already license MSDN; and that means TFS 2010 is essentially … free, so personally I don’t think there is much of an argument when it comes to cost – and if sys admins moan they need another server, kick them hard. Surely they should know their usage patterns and TFS does not actually need that much power for small dev teams … If they are saying they need another server, it would make me think they haven’t tracked usage on the existing ones properly!

Development Team Commandments

I’m going to try and add to these as  I think of others, but essentially the rules that I see are:

* Only check in code that compiles.
* Be sure to check in all dependencies (yes, even external DLL’s) that are not part of the standard shipping platform. If it doesn't build on a clean machine, you’ve messed up.
* Check in regularly. If its incomplete, use a private branch or shelveset (TFS)
* Not sure about something? Then discuss it with the technical lead.
* Spend the time and write some unit tests for business logic. It will save you time later.

Azure and the 'Aborted' / 'Recycling' Role

I recently uploaded new, very basic, template project into Azure as the basis of something I’m working on, and after the pre-requisite eternity waiting for it to initialise realised that it was cycling between Aborted and Recycling states. Very odd.

So I tried again. Same thing.

I gave up and contact support.

I have to say, they were quick dealing with the request, but the information they gave was … to say the best … rather annoying.

The problem was I used MVC3 they said, and the DLL’s weren't included.

Fair enough.

 

BUT, surely the Azure packaging tooling should be more intelligent? If Microsoft’s own libraries are not preloaded on the platform (only .NET 4 is from what the engineer said), then surely the packaging tool should identify references that are not present and either warn or include them. Not just carry on happily.

Not only that, the information should be exported to the NEW azure portal, not hidden away. I’m told the information is available via RDP login (which has to be enabled … yes you guessed it … in the configuration when you deploy – so yet another delay!), but surely thats overkill for most web roles?