The development process
This is a chapter from my newly-released book about developer selection and beginning IT projects – I hope you enjoy it. For more on the book, please send me a quick message via my website.
Your development methodology – waterfall vs. agile
In the early days of software development, the prevailing project management paradigm was: do your market research, design the system, get it developed, pass it on to testing, then put it out to market.
This became known as waterfall development because each stage was completed in its entirety before moving to the next. If you are technically minded, you may be tempted to use this approach yourself – intending that by the time you chat with software developers you’ve already checked your market and designed the system (just hand them the spec, and go!)
However, as technologies, communication and user expectations have evolved, most software development has changed to what is known as an agile methodology. Using this approach, the client (you), developers and end users all work together in iterative cycles to design the product.
Most people’s concern with agile development is that you are putting an un-finished or un-tested product in front of your customers. However in practice this is rarely the case (you can still test and conduct market research within each of these stages) and it is offset by many other benefits:
- the contribution of real-world use cases provided by your customers
- your software developers have seen a lot of businesses start and fail, so they can often advise in other non-technical aspects of your business
- your developers and users will appreciate the participatory culture
- if something goes wrong, your agile processes will easily facilitate rapid deployment of bug fixes and product updates
- you will be more responsive to customer feedback and changing competitor trends
User-driven development
Agile development also opens the door to another modern paradigm - user-driven development. This simply means that as well as designing the system based on your own expert knowledge, you constantly obtain feedback from your users and integrate it into the next release cycle.
I cannot emphasise enough how valuable this resource is. Your user-base is a pool of real-time market researchers & product testers with a vested interest in the success of your product. And they’re usually free!
Good product and process design can easily include these people into your development lifecycle, so make the most of them.
An easy start for your user base is your friends and family. They know you and your limitations and they are nosy enough to be prepared to work for free. Hopefully you have the kind of friends that will give you honest feedback if the product is not working correctly (if they don’t do this, there’s not much point using them actually).
After you exhaust your friend and family network, you need to quickly expand your beta testers to include:
- people that don’t know you personally (they are more likely to give honest, un-biased feedback)
- people that are actual end users of the final system. There’s little point building a professional accounting product and then getting your ten-year-old niece to use it.
- people that don’t know you personally (they are more likely to give honest, un-biased feedback)
- there’s a bit of a lead-time in getting beta testers, so I recommend you get started before you have a product to show them.
Strategies to attract testers are up to you, but things that I’ve seen work include:
- have some kind of ‘pre-signup’ form which gives benefits to early adopters of your product
- allow your beta testers to invite a limited number of their own friends to also be beta testers - create a sense of opportunity and privilege by purposefully keeping this number low
- identify specific customers you’d like to have and invite them in an advisory capacity - many will be flattered and willing to participate if it means influencing the product design in a direction of their choosing
Deployments & upgrades
Once your software is developed or has a new feature added, the job is not done - it still has to be deployed to the customer. If your software is on the web, this means copying it to a server or to the cloud. If your software is a mobile app, it means deploying through an App Store. Many software products are, in fact, over multiple platforms, so you may end up making multiple deployments.
People underestimate how much effort goes into deployments, but trust me - it’s significant. What’s more, it’s the first experience your customer has of the new features so it is critical to get it right. Large software companies have dedicated ‘ops’ and infrastructure teams to manage this stuff, but in your case it’s probably going to fall to your developer.
The purpose of this section is not to provide technical assistance, but instead to give you a little bit of warning that this is a legitimate and necessary part of the software development process. So when your developer starts talking about “continuous integration”, “rollbacks” and “integrated testing”, don’t be angry at the extra costs, be grateful that they know what they’re talking about (check out the geek-speak appendix at the end of this book for details on each of these).
Depending on your requirements, your deployment processes may be as simple as a file-copy to the server, or more complicated than the software itself. Discuss your options and requirements with your developer to find the right balance, and be prepared to add it to your budget.
There are different levels of development
The car-wash down the road from me has a big sign outside offering their different services. For $20 they’ll pretty much spray your car with a hose. For another $20, you’ll get it waxed and for another $20 they’ll clean the inside too. However, regardless of which service you choose, you would still describe your car as being “washed”.
In a similar way, people think of their software as being “developed”, but within that there are a multitude of services which your developer may or may not be doing.
This ambiguity might lead to problems for you later if there is a disparity between what was provided and your implicit expectations.
It is up to you to find out beforehand exactly what services they consider to constitute “software development”. I’ve helpfully listed the most common services in the table below:
| Service | Do you need it? |
|---|---|
| Assistance with establishing your software requirements | Depending on your level of technical ability, you may already have a complete specification ready to hand to the developer. Otherwise you will need your developer to assist you with this |
| Building your software | Um, of course |
| Building an extensible architecture | Yes, unless you’re doing a proof of concept |
| Documentation | Prudent, especially if you are expecting to switch developers or take the project in-house later. Documentation can be retrospectively added at very little overhead, but this is no good to you if your relationship sours suddenly |
| Automated deployment processes | If you plan to release regularly (e.g. at least once a week) then this will save you a lot of money and stress |
| Automated tests | Yes, unless you are in the very early stages of a product (e.g. MVP) or you are prepared to manually test every time you release the software |
| Design & user experience | Depends on your audience. If people’s first impression of the software is what they see, then yes, you probably want design |
This table can also explain why different developers will give you vastly different quotes for your software. Some will take your requirements at face value and just deliver what you asked for, while others will implicitly know that you need additional services and include them in the quote. Neither mechanism is wrong - just be aware of it and talk to them.
To conclude…
The most important thing you can do when embarking on your software development project is to be prepared. Take the time to understand the different things that go into your project and don’t let yourself be overwhelmed or intimidated by technical jargon.
Software development is a specialized field, but that doesn’t mean it should be inaccessible to non-technical people. Finding a developer that shares your vision and that you can communicate with is key to bridging this gap.
Have fun, and I wish you the best of luck. If you have any questions or want to share your successes or failures, come find me at www.blackballsoftware.com.
