A top ten credit crunch development list, done in three

No software development vendor worth their salt would let the credit crunch pass us by and miss the opportunity to pump out a few snappy PR messages woven around the opportunity to “reduce software development lifecycle costs” would they?

Well, to be honest with you – it’s been few and far between. Perhaps a focus on general cost savings has really been happening to such a degree that companies have barely had time to think about getting some PR value out of it.

While I can’t name a big vendor or ‘solution provider’ or consultancy that has really overplayed this tactic, it took a lesser-known outfit in the shape of a company called Experimentus to chase me down on this and offer me some pointers.

The company’s ‘top ten’ recommendations for a cost saving approach to software development are arguably at risk of being a list of ‘stating the blindingly obvious’, but they can probably be condensed into three points, so here goes.

Firstly, define functional and non-functional requirements properly, document them well and distinguish between the two. This is good advice if you want to avoid building a system that does exactly what the customer wants – but is difficult to use, slow, insecure, unreliable, or is not scalable.

Let’s skip over version control and configuration management and take those as read shall we?

Secondly then, Experimentus advocates a focus on preventing rather than detecting defects. It’s so obvious it’s painful. But it’s not normally phrased in this fashion. Most vendors like to flag wave about the fact that developers will naturally produce defects and talk about the fact that their software can detect them afterwards. Prevention is better than cure after all isn’t it? We should hear more of this then I feel.

Skipping over automated testing a couple of other nuggets, let’s wrap up with one more.

Sanguine development advice from Experimentus is to begin UAT (User Acceptance Testing) test design during requirements definition. Yes please. Yet again, this is another rather obvious point that is often overlooked. The company says that, “If an organisation is using the ‘V-model’ of software development correctly, then the test team should be involved with the project from the very beginning – during the requirements definition.”

So that’s it, let’s keep it short and just sample a taster of the weighty top ten list I was sent. Of course, I am being cruel to suggest that the company produced seven other pieces of advice that were any less worthy, but when they bill themselves as “THE leading UK software quality management solutions consultancy”, I would argue that they build themselves up for a fall. Or at least a lighthearted critical jibe. Wouldn’t you?