Tag Archives: software testing

Countdown – Two Days to Go

Share

Building software isn’t necessarily more difficult than building a building or a tunnel. You don’t get wet, or get mud on your boots. You don’t work with dangerous machinery or risk falling from a high place. You don’t need a hard hat to write software, you just need a chair, a warm place, a mug of tea and a computer.

building site

You would think that there are fewer unpredictable things in the logical space in which we software developers work (barring the malfunction of other pieces of software that form part of the system – equivalent, I suppose, to malfunctions in materials that form part of a building). It’s not an exploration of unknown conditions, either. You don’t unexpectedly discover that a logical turn takes you into more difficult ‘logical’ space, whereas the digging of a tunnel might take you into muds of different textures and load-bearing capability.

Assuming that requirements don’t change, there should be nothing unexpected when you’re programming, and nothing should get in your way.

So, why is it so difficult to finish software systems on time?

Perhaps the answer lies in the fact that whereas a building is conceived fully before construction starts – its outline, its height, its weight, and all its components and how they’re to be put together – the details of a software system are ‘worked out’ as it’s developed. A full description of it would be the system itself. Perhaps it’s like the development of a mathematical proof. The destination, the theorem, may be known in advance, but the tortuous path towards it has yet to be described. The full description is the solution.

We’re just two days away, we hope, from releasing a new version of time@work. We’re late, of course. We should have been two days away some weeks ago (perhaps months, if I’m really honest). But I’m not complaining. This is the way development goes. We’ve moved the goalposts a little, we’ve found some things more difficult than we’d expected. We’ve reversed out of wrong turnings when the ‘final’ version of a new feature wasn’t as easy to understand and use as we’d imagined. We’ve sometimes not anticipated that a change in one part of the system would cause logical problems in others. Who can eliminate such issues from the software development process?

It happens every time. Even after years, our estimates are sometimes wildly inaccurate. I hesitate to abandon estimation, since in software development you must choose between priorities, and knowing how long something will take and therefore how much it will cost is an important component of that judgement. I’m still not ready to shrug my shoulder and go down the route of ‘It will take as long as it takes.’

But it’s wonderful to be just two days away (or three, or four, perhaps) from Version 5. It’s been a year since we produced a major new release, and this one contains some exciting new features. I’ll list them when we get there in a few days time but for the moment we’re doing final assembly and a bit of cleaning up.

  • We need a revised demonstration database to issue with the new version. Not only must all the data be updated from 2014 to 2015, but changes have to be made to illustrate the new possibilities in the software.
  • We need to update the system help text with text from the new complete reference guide to the product.
  • We need to make some final graphical adjustments (consistent fonts, colours, styles, new login screens).
  • We need to fix some final bugs.
  • We need to  run a ‘release check’ across the entire product to test as many functions as possible in as many permutations as time allows (testing all of them would take longer than the lifetime of our solar system).

We do this with a series of iterations of the product. The problem is that this means we’re tilting at a moving target. I received a new iteration on Friday and worked on it over the weekend. Everything that wasn’t working before worked, but one thing that worked in the previous iteration didn’t work in this one.

Perhaps just one more iteration, today or tomorrow, and we’ll be ready to release on Wednesday. Fingers crossed.

Developing a Software Package – Sometimes the Nightmare Ends

Share

I’ve posted two articles on what you need to think about if you’ve decided to develop a business software package. You might have a fantastically good idea, but developing, marketing, selling and supporting a package isn’t as easy as you might suppose. There’s far more to worry about than logical design.

software pack

The Nightmare

The Nightmare Continues

  1. Have you thought about quality?

If you’re building parameterized software then it’s going to be capable of millions upon millions of permutations. Have you any idea how you’re going to test a sufficient number of these? Or even the most commonly used ones? The more that your package can do, the more ways it can go wrong. The quality level that you aim for is a matter of choice. Perfection is impossible, and near-perfection possibly unaffordable.

  1. Have you thought about documentation?

You’ll need help text (and the capability of multi language help text), reference manuals, installation manuals, user manuals, training manuals, demonstration manuals, and so on. Your customers and resellers expect this (though don’t bother printing them). Electronic versions that can be accessed through a browser will do quite well enough.

  1. How much of the product should you finish before you market it?

Your vision must be complete before you start, with an outline design for everything you intend to develop. You’ll want to sell your package as soon as you can, to make back your investment, but If you sell too soon, you’ll get diverted from your vision, and most dangerously, you’ll find yourself in obscure alleyways of customer-specific code. But if you sell too late, you’ll have used up all your money.

  1. And have you thought of how you’re going to take your package to the market?

If you’re not yourself in possession of an international company, then if you’re going to sell beyond your domestic market you’re going to need distributors and resellers. You’ve got to see things through their eyes. How can they make money from your product? What will be their upfront investment, and their ongoing cost of sales? Is the balance between service revenues and licence fees the right one for them? Can they learn enough about the product quickly enough to be able to present the product and then implement it?

You need to think of the marketing material they’ll need, the return on investment arguments they’ll use, the contracts, the multi-lingual support service, the case studies, the training, the guidelines you’ll give on implementation duration and costs, and so on. If they can’t make money, then there’s no way you will.

And your pricing model has to be one that can, in theory, and even after discounts, return a profit.

But whatever you do, don’t try to set up a reseller network until you’ve won some deals yourself. When recruiting resellers, just as when selling to customers, references are everything.

  1. How are you going to win your first customers?

Whether your first customer is your own or a reseller’s be aware you’re not going to make any money from the first few deals. Your first customers won’t buy your package, however unique, unless you give them a special deal and extraordinary service. It’s hard to sell without references. You have to ‘buy’ the first deals.

  1. And have you thought about how you’re going to keep your development team happy during the long development period?

If you do lose a developer, is his code sufficiently well documented that another can take his place and maintain his code?

  1. Have you designed a feedback mechanism so that your customers’ wishes are reflected in subsequent versions of your package?

If you don’t listen to your customers’ needs, they’ll soon stop paying for maintenance.

  1. Have you made a prudent investment plan to take you from concept to sales?

If you can’t afford the long-term investment that package software requires – the employment, travel, technical and marketing costs that will take you to your goal – then don’t even think of beginning.

My company, systems@work, set out to develop software for professional services (and expense and forms management) more than a decade ago. Did we ask ourselves all these questions when we began?

Some of them, certainly, but by no means all. time@work is a ‘best of breed’ package for services organizations from accountants, engineers and lawyers, to architects, consultants and charity workers. It’s now used by more than 250 companies from Tokyo to Sydney, from London to New York.

If we’d known there were so many questions, we might never have started. During the first few years there were certainly times when we were close to giving up. But if there are two questions we certainly should have asked ourselves more aggressively, they are ‘How are you going to win your first customers?’, and ‘How are you going to take your package to the market?’

We’re securely profitable now, and my anxieties, if any, are operational ones rather than existential ones.

So, if you have a dream and you can answer these questions positively, and if you’ve got nerves of steel, then good luck. After all, someone has to write these packages.