Best Practice Software Development

/

As part of our business focused on accelerating (or fixing) New Product Development projects, we also provide software tools. Whilst not the focus of our business, they are essential to allow us to do what we need to do, much the same way that Word processing software is now an essential part of an author.

We do all our own software development, i.e. we write our own software based on standard applications such as Microsoft Project and Microsoft Excel to make it easy for our clients to adopt. It is important to us that we adhere to the best practices we preach.

What follows is an overview of those practices.

Identify one or two customers as a beta tester

  • Don't have more than about two beta testers initially. You will be swamped just supporting them. Start small and focused and expand over time as the product becomes more stable.

  • They have a real business need or problem right now that your product solves

  • They either have no current solution or one that is inadequate

  • They are willing to use it to solve a real problem

  • You know them well and will be tolerant of bugs and crashes that are inevitable in the early days of prototyping

  • They are willing to spend the time testing, and the likelihood of this happening is dramatically increased if they have a real need

  • They are willing to let you observe them use it when in a small group. There is nothing more insightful than observing a client/customer use your product: you see what they do and how they use it. What may be obvious to you may not be obvious to somebody else.

Develop a prototype quickly

  • Think about the architecture of the product. Time spent thinking through it upfront will pay dividends later when new features are added.

  • Give your beta testers early prototypes (likely a little rough) in order to get early feedback. This is the stage when changes are the least expensive and based on the concept of rapid prototype development or do-it, try-it, fix-it cycles of learning

  • The worst thing you can do is go too far with development without any customer feedback. Changes late in the day can be expensive and time spent developing new features can be wasted

  • Make sure your beta testers know this is a beta product. They will be more tolerant when things go wrong.

Fix changes quickly

  • When you get feedback from your beta customer, fix them quickly (within a day or two) and get a new version back in their hands as soon as possible. Every day counts as each day they don’t have a fix is a day they can’t do their job.

  • Don't wait for all the changes to be made (if there are many). Better to get the most important ones fixed then a new version in their hands while you continue working on the remaining changes.

  • It is inevitable that the product you finally deliver will look nothing like the first versions. Sometimes major structural changes may need to be undertaken. The customer will also spend significant time using your product and entering data, so make it easy for them to upgrade between versions.

  • In the early days, you may well be simply sending files to your beta users and asking them to put them in a folder. As time goes on however, make it easy for them by implementing an updater and an installer, so they can get the latest releases with just a few mouse clicks.

Manage changes based on cost-benefit

  • Changes in the early days are usually the least expensive. Changes later can be expensive. Despite what many philosophies advocate, a design is never "frozen". A good idea is a good idea and should not be rejected because of a "freeze". What is important is ideas and changes are managed. We find the best way is to do a cost-benefit analysis: implement easy changes/high value changes, defer low value/high risk changes

  • If you have a well thought out architecture, sometimes changes that add a lot of value can be made with only the addition of a few lines of code. New functionality however may involve re-writes of existing code, changes to the structure of the tool, etc. The risk of breaking something is high, so these types of changes should be deferred to the next major release.

  • If course, there may also be something "cool" you can do very simply that your beta testers may not have even thought about - use common sense

Understand your customer's business need

  • The best products are those designed around solving real needs and real problems - this is why you want to base a significant part of your product around your beta testers application of your tool and their feedback (no matter how small)

  • A tool has to solve a business need or some other need that a customer currently lacks a solution. Developing software or a product to solve a non-existent need will only lead to disappointment later down the road.

  • Adherence to these practices will pay dividends later. You will end up with a product that solves a real need and users will like it because it will be based around how the use it.