February 4, 2014

...Learn TDD with Codemanship

Five Tips For Software Customers

Congratulations! You are now the owner of a software development project.

Bespoke software, tailored to your requirements, can bring many benefits to you and your business. But before you dive in, here are 5 tips for getting the most out of your software development team.

1. Set Clear Goals

Many customers who have reported faults with their software development team can trace the problem back to one common factor: the developers didn't have a clear idea of what it was you were hoping to achieve with the software. Work closely with them to build a shared, testable understanding of your business goals so they know what to aim for and can more objectively measure their progress towards achieving those goals.

2. Be Available

Another very common fault reported with software development teams can be traced back to the fact that the customer - that's you - wasn't there when they needed input. This can lead to delays while teams wait for feedback, or to costly misunderstandings if the team starts to fill in the blanks for themselves. The easier it is to get to speak to you, the sooner things can move along.

3. Make Small Bets

Your software development team costs money to run. A day spent working on a feature you asked for can represent an investment of thousands of pounds. Software is expensive to write. And there are no guarantees in software development. Even if the developers deliver exactly what you ask for, there's a good chance that what you wanted might not be what you really needed, and the only way to to find that out is to "suck it and see". In that sense, everything they create for you is an experiment, and experiments are risky. Sometimes the experiments will work, sometimes they won't. The key to succeeding with software development is to invest wisely in those experiments. rather than take the entire budget you have available and bet it all on one giant experiemnt to solve all the problems, consider breaking it up into lots of smaller experiments that can be completed faster. If your total budget is £1,000,000, see what the team can achieve with £20,000. The more throws of the dice you can give yourself, the more likely you are to come out a winner.

4. Don't Ask, See

You may have read horror stories in the news about £multi-million (or even £multi-billion) software project failures. A typical feature in these stories is how the executive management (i.e., the customer) didn't know that the project or programme wasn't on track. That is because they have made the most basic mistake any customer on a software project of any size can make - they relied on hearsay to measure progress. Large IT projects often have complex reporting systems, where chains of progress reports are filtered upwards through layers of management. They're relying on middle managers to report honesty and accurately, but on these large projects, when things start to deviate from the plan, managers can face severe consequences for being the bearers of bad news. So they lie. Small wonder, then, when the truth finally emerges (usually on the day the software was supposed to go live) executive management are caught completely unawares.

By far and away the best mechanism to gauging progress in software development is to see the software working. See it early, see it often. If you've spent 10% of your budget, ask to see 10% of the software working. If you've spent half your budget and the team can't show you anything, then it's time to call in the mechanic, because your development team is broken. Good development teams will deliver working software iteratively and incrementally, and will ensure that at every stage the software is working and fit to be deployed, even if it doesn't do enugh to be useful yet.

5. Let The Programmers Program

You know that guy who designs his own house and tells the builders "this is what I want" and the builders say "it won't work" but the guy won't budge and insists that they build it anyway, and, inevitably, the builder was right and the design didn't work?

Don't be that guy.

Let the technicians make the technical decisions, and expect them to leave the business decisions to you. Each to their own.

And if you don't trust the developers to make good technical decisions, then why did you hire them?

6. Things Change

It's worth restating: everything in software development is an experiment. Nobody gets it right first time. At the beginning, we understand surprisingly little about the problems we're trying to solve. At its heart, software development is the process of learning what software is needed to solve those problems. If we cling doggedly to the original requirements and the original plan, that means we cannot apply what we learn. And that leads to software that is not as useful. (Indeed, often useless.) Your goal is is to solve the problem, not to stick to a plan that was conceived when we knew the least.

The plan will change, and that's a good thing. Get used to it. Embrace change

Posted 3 years, 11 months ago on February 4, 2014