How Good Is Your Software Team

Just how well does your software team rate? Answer the following questions it won’t take a minute honest.

  1. Do you use source control?
  2. Do you do daily builds?
  3. Do you use bug tracking?
  4. Do you fix bugs before adding more code?
  5. Do you have an up to date project plan?
  6. Do you have a specification?
  7. Do your developers have a quiet environment?
  8. Do you have testers?
  9. Do you do UAT testing?
  10. Do new developers have to write code at their interview?

Didn’t take long did it now let’s look them in turn.

1. Source control is a must have, not only does it keep your precious source code safe but developers don’t usually know what the last developer did, how good he was, whether the code he checked in actually builds. A good source control versions your code, keeps a history and allows roll backs to an earlier version.

2. Unless you perform regular builds on your code you never know what state it is in till you come to work on it. The process can be automated not only to build the whole codebase on a regular basis but to create single step checkout and builds (overnight if required) the more steps you need to get to the point of building the code the more prone to errors. Daily builds on the whole code base will highlight errors such as a developer checking back in the code but forgetting to checking new classes or libraries, the code will obviously build on his machine but won’t for anyone else checking out the code (even worse if he locks his machine and goes on holiday).

3. Without an organised listing of bugs you are going to ship not only low quality code but probably re ship the code with reported bugs unfixed, you can’t keep all of the bugs in your head. As a minimum your bug tracker must keep:-

  • Steps to recreate the bug
  • Expected behaviour (without the bug)
  • Who spotted the bug
  • Who is to or has fixed the bug
  • Current status of the bug

4. If you are not fixing the bugs before adding more code you are simply compounding the problem, not only will it make bug fixing harder (you can’t even attempt to debug till the current code compiles) but you could well be introducing new bugs to the existing ones.

5. The code is important to the business, it is important for them to know when the code is going to be ready, developers are notorious for saying “however long it takes” unfortunately that doesn’t (and shouldn’t) cut any ice with the business,  they have to plan in advance for  when they expect to get ownership back of the code and the only way to do this is to plan ahead and keep the plan up to date, from the developers point this means that there is a good chance that you won’t suffer from “feature creep” and end up working on the code for the next ten years.

6. If there is one thing about spec’s it usually that everyone agrees you should have one but no one provides one.  As a result, when teams consisting solely of developers  approach the problem they go straight for a solution and dive straight in to coding resulting in much higher costs to fix any design or code issues. Software which wasn’t built using a specification quite often results in a badly designed product which doesn’t meet requirements and timelines spiral out of control.
7. We all know the developers work best when they can get into “the zone” where they can fully concentrate on their work, the trouble is that it is hard enough to get into “the zone” as it is without constant distractions, phone calls and the ever present “can you do this for me it won’t take you long” interruptions.

8. If your team doesn’t include at least 1 tester (ideally to every 3 developers) you are probably at best using a highly skilled developer to do a lower skilled job and at worst delivering buggy code to the business, saving money on not having testers is a false economy and can dramatically cut delivery times.

9. You simply have to have UAT testing, how many times are users given a new system and told to get on with it, more often than not they have had no input as to how the system works, scarily end users won’t even be asked what is wrong with the old system. UAT is an invaluable must have step in the process; no code should be delivered without first going through UAT.

10. Is there any other professional you would employ without first checking their work or at the very least have them highly recommended by someone you totally trust.You are placing a lot of trustthese people not to bring your business down, not to destroy the trust you earned for your business with your clients, every new developer should be asked to show competence to the level that the position requires.


If you would like any help or advice with your web presence or would like more information on cloud contact us.

At CodeSpinnewe have over 25 years experience of producing custom software.

If you would like to get more tips, or would like to receive a free 90 page eBook on Search Engine Optimisation (SEO) please visit

Alternatively if you would like us to discuss your software requirements contact me at:

Tel: 07850 009750
Twitter: @CodeSpinner

Tell me and I’ll forget, show me and I will remember, involve me and I will understand (old chinese proverb).

Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: