Kablingy

I cringe when software developers say that there's a bug in the software. It feels like the developer is shrugging off any responsibility about the matter, as if a moth randomly flew into the computer and started to swap ones and zeros about.

In fact, the developer has created a fault, error, mistake or defect in the software. If you determine the root cause of the defect, its usually because the software wasn't tested adequately, the developer used risky programming techniques, and he/she didn't have a second or third pair of eyes reviewing the code. 

It's a reflection of the general lack of professionalism that the software developer community exude. We're not accountable for our actions, so we brush of our mistakes by saying a bug flew into the code.

So developers, please take responsibility for your code. You created a defect, not a bug.

This is based on a few horror stories we've heard from customers recently, who were unhappy with their previous software provider.

Here are 5 questions we think most software consultancies aren't asking their customers. 

1. What are you quantifiably trying to achieve?

Before you hand over your money for software, it's worth asking what you want to achieve from this investment. Do you want your new software to generate a 5% increase in foot fall? Perhaps you'd like €2000 per month deposited in your bank account while you sleep? If nobody asks you this question, then it's a little difficult to know if the software project was a success or not. If you don't think about how to measure success, then your software consultancy will undoubtedly claim it when the project is finished.

2. Why do you need new software and is there any existing software that would do the job? 

Another way of asking this question is "What would be 90% as good, but would be 10% of the cost?". Quite often, a combination of some existing software services e.g. Highrise, Dropbox, Youtube & Overtake (shameless plug) will allow you to achieve most of what you want at a fraction of the price of a perfect, custom and expensive software solution.

3. What is the absolute minimum feature set you need?

If you have a new idea for a software service, and you're not sure if it's going to work, then don't invest upfront in unnecessary features. For example, there's no need yet to build a fantastic user administration and reporting system. Why? Because you don't have enough users yet to necessitate it. You don't have any data to put into the report.

Remember that most software consultancies will be happy to take your money and build unnecessary features for you.  Also, forget scalability for now. You don't need the $1000 hosting package, yet. Concentrate on the bare features needed that will give you the feedback to know if the project is going to be a success or not. If a project is destined for failure, kill it as early and as cheaply as you can.

4. Who are the different types of users?

Identifying 3 or 4 archetypal people by name that will use your software is invaluable to the design process. Speaking in terms of what "Jim the account manager" or "Kate the sys-admin" needs is far better than always referring to The User, or as we call him - The Elastic User. If you build a system for the elastic user, you'll probably end up with software bloated with features. However, by defining user personas, you will be able to identify what features are important for what persona, which is the most important persona to satisfy, and more importantly what features can be eliminated from the system.

5. Who owns the code?

In our opinion, this question doesn't get asked enough, even though it's pretty simple to answer. If you pay us to build custom software, you own the code. If you use one of our software subscription services, then we own the code for the service and you own the data you put into it. We also recommend that you pay for the server hosting directly, and own your website domain. This will avoid any unpleasantness if and when you want to switch software providers.

It's a good idea to have a section covering these points in the Master Services Agreement with your software provider.

You do have a Master Services Agreement, don't you?

As a consultancy,  how can we define project success?

Typically in a project, a client asks for features and a software development consultancy delivers those features, hopefully on time, on budget and to a professional standard. Then everybody claims success.

But how do we know if it was a success? Did we really fail? Could we do better than this?

We think the best way to address  project success is to first understand the project stakeholders' real requirements. The problem is that even the most enlightened agile developer can mistake features and designas project requirements. But by continually asking why, and not how, we can fish out what the client really requires. Consider the following example:

A sample set of  so called "requirements"

The client needs us to develop a web application with the following must have features:

• Users can sign up for free and upload and sell their own books
• Room for Google ads, and sponsors.
• User can upload their own avator and connect to  authors of the same genre
• Forums
• Integration with MySpace, Twitter
• Facebook App

This is not untypical of the kinds of applications we are asked to build. However, if we continually ask our client why (5 times will do the job) she wants these features, we might actually get to the real requirement which is:

The client wishes to increase her passive income by €2000 euro a month, within 6 months

Now that's a requirement and that's exactly where we should start the conversation.  Now we can start to talk about things like the business model  e.g.

• Why is she offering a free sign up? Why not charge her users a flat fee per month or percentage of the sales? 50 subscribers on a €40 a month plan will achieve the goal in a more predictable manner than advertising. Not to mention, can she realistically get enough traffic within 6 months to justify the advertisers fee?
• We might ask her if she would consider trying to aim her product at businesses instead of the consumer, since businesses are usually happy to pay for services, while consumers expect everything for free. Would she consider working with a dedicated sales team to get those 50 subscriptions within 6 months?
• Why bother inventing adding social network features when she could integrate with another established one or avail of a social networking platform service. Will the social network aspect help her to achieve the €2000 in 6 months goal at all?

And so on. You can see how this way of thinking can drastically alter the list of must have features from above. Perhaps the feature list now looks like this:

• Build a subscription based service aimed at professional authors. Authors get a shopping cart and microsite CMS with a spot for video blogging. Charge 40 euro a month for this service.
• Sample chapter of the book can be downloaded as a watermarked PDF
• Offer an auxillary service connecting authors with publishing companies

So coming back to the title of this post, how could we define project success? How about this.

• Get the real requirements. Make sure they have been quantified. If you're feeling saucy, you could even consider a requirements specification language like planguage. Don't be put off by the phrasespecification language, it's quite accessible really and not at all stuffy.
• Get your stakeholders to prioritise the top 10 requirements. Each requirement fits on an A4 sheet of paper. There's no need to mention features - that's for the design and development team to figure out.
• Drive the design from these requirements
• Then, do all of your usual wireframing, test driven development, iterative planning, continuous integration and all that good stuff etc.
• Measure continuously and communicate with your stakeholders on whether the requirements are being met, and thus if the project is going to be a success.

The masters in this department are Tom and Kai Gilb. Take a look at their site, publications, and free books for a wealth of information on requirements gathering and measuring project success. It's exactly what's been missing in the Agile software movement.