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).


Tips on improving your copywriting skills

Now is the time to start taking advantage of all the existing and emerging social media platforms currently available to you. Whether you are a business looking after your own social media campaigns, or a consultant working on behalf of a client, it important to get it right and this is where learning even the basics of copywriting skills will pay dividends.

Social media has been around for some time, initially these were great platforms to help build brand awareness and gain user interaction in fact they still are, however, in some instances they can be used to help drive traffic and improve conversion rates as well as playing a huge part in a business’s rankings with the many search engines.

Now is the time to start taking social media more seriously, whether it’s getting the basics right, or in understanding social media strategies, the following copywriting tips are worth remembering when using any media platform:

Spelling and Content

There is nothing worse than visiting a site that contains spelling mistakes or content that doesn’t read well, from a business perspective this will at best this makes the company look unprofessional and careless and at worst it can put a stop to any user interaction, rendering the whole process pointless.

Don’t beat about the bush

Whether you are writing a full page or trying to tweet a message in 140 characters or less, it is important that the message is to the point, any followers will simply lose interest if the message is “wordy” and not to the point, this doesn’t mean avoid having a personality it just means be clear and concise in what you are trying to convey.

Don’t lose the connection

Keep a clear connection between your brand image and social media personality it is an all too common mistake for many brands using social media, for example, a company may have the perception of being vibrant, new and exciting, but their social media activity may not reflect this, so write in a way that will enhance your brand image, whatever that may be.

Be creative!

It is important to focus on getting the user to click on a link, or to look at something you have shared, one way to do this is to be a little more creative with your posts or tweets, so instead of tweeting, “Here are some copywriting tips”, you could create more interest for example by saying, “For tips on improving your copywriting skills, follow this link”.

Make time!

It is all too easy to forget about updating social media content, especially if you are busy, however, every little helps, one way is to set yourself reminders to send out a tweet or update your status at various intervals during the day even if you can’t find time to post a full article.

Set aside some time to actually engage in online conversations with others, the more “active” you are the better this will be for your company’s exposure.

Most of all – Enjoy it!

The whole point of social media is to engage with others this is why it is important to enjoy the experience and not go for the hard sell which will put people off.

Potential customers or clients would rather take time to talk and engage with a company that is actively seeking their interaction rather than abruptly trying to push their products or services onto them.

Above all have fun! this will show in the way you write and the way other people perceive you or your business don’t see it as a chore but rather an integral and important part of online marketing.

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

How to Gather Better Requirements for Custom Software Development

Deciding the business requirements when going bespoke can be quite difficult this is because software and business systems can become very complex and as a result there are lots of places where miscommunication and assumptions can occur.

So why is “going bespoke” any different, there are many other industries where a contracted individual creates something for a customer, building construction for instance; for example when you buy a home from a builder.

Usually the builder has various show homes that you can visit and look around, usually they have examples of all of the different options that you could purchase for your new home, and in any case people are generally familiar with houses, they know what to expect and they know what not to expect, so in reality when you purchase a home from a builder there are relatively few choices that you make and the choices that you do make as a customer are things that you are very familiar with.

In software development this would be similar to purchasing a software product that is already built and then modifying it. It’s a fairly low risk undertaking and you usually get the chance to try out a version of the actual software you are going to purchase.

However, custom software development is a whole different “kettle of fish”, It is much more like designing your own house.

When designing your own house there isn’t an example you can go visit, whilst a builder could point out certain features of other similar buildings that you could see, often you are left only with a set of plans or drawings of what the final structure will look like.

It can be hard for the customer to visualize what the finished structure is going to look like, ok you can look at the plans and see that a bedroom is going to be 10′ x 15′ but it is a little more difficult to really get a sense for what that room is going to feel like when you walk in or how the furniture will fit, how quiet it will be etc.

The same is true for bespoke software development. It can be quite difficult for non-technical customers to really be able to visualize the finished system and how it is going to work, and because they can’t really see the completed system in their mind, it can be very difficult for them to explain to the developer how it is supposed to work.

So what should you do? Here are some best practices that can be followed when developing a requirements document for bespoke software applications.

Draw a “model” on paper whenever you can, create examples of how you want your software to work give examples of major functional features so that you and your staff can “walk through” different screens and functions, get a better feel for how things might look and work.

Map out prototypes that walk through complex functionality and “use cases”

Create mock ups of key screens that show as much functionality as possible use something like Visio tm (Microsoft) or Pencil ( which is a free open source tool but there are many more

Create annotated visual functional requirements documents. I have written a few functional requirements documents over the years and have found that if your requirements document is entirely text that describes every piece of the system, people will generally just nod their head and say yes to everything.

The truth is that no matter how eloquently you write and how painstakingly you describe your requirements, people by their very nature prefer things to be visual, they need to see it to really understand how it is going to work, where possible you should always add a diagram or flowchart.

Remember you are striving to improve the transfer of knowledge between yourself and the developer. The more the developer knows about your business the better they will understand the problems, the better they will be at describing the solution.

Bespoke software development can be quite challenging, however, with a little work you can make the knowledge transfer between you and developer much more efficient.

Alternatively, leave it to the professionals, get them to do the hard work whilst leaving you to “sanity-check” and simply approve the final requirements.

At CodeSpinner we have over 25 years experience of producing specifications and requirements.

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