Every customer of a software company naturally wants to get the most out of what they pay for. One of the sought-after “properties” attributed to good software is flexibility or changeability. Everyone understands it in their own way, but the general approach is that mutable software can be more easily adapted to the changing environments in business and technology. If the market and users require a change, it can be implemented more easily without undue effort. But does all of this correlate with the customer’s desire to design the product economically? Not directly.
Early planning helps increase the ROI of the project. A quick start is good, but it doesn’t help the software owner see into the future. But to do this, the software owner must understand the goals of the product and personal goals, and first build relationships with a professional development team that brings together project management, design, development, and quality assurance into one work process.
The agility and changeability
Many software companies work according to agile principles. They claim that iterative development is a great way to quickly respond to changes in customer requirements. While this is the case, it doesn’t guarantee mutable software as a result, so don’t confuse these two terms.
An agile approach to running projects allows you to change your product when needed with less effort and in less time. But the changeability of software is the cornerstone that can be laid right from the start. It is none other than developers who create changeability; The agile approach can help you to use this adaptability in the future.
The balance you need
Flexibility/changeability of the software alone is not cost-effective. It can neither be called good nor bad in itself. It’s good when needed when you need to customize your software. There are basically three options:
• Be flexible where you need it (win).
• Make flexibility where you don’t need it (lose it). The other danger is that “over-flexible” software will be harder to support in the years to come. If more customization is needed, there’s no guarantee you’ll get the same team that built it to get the job done. Meanwhile, the developers who don’t know will need more time to figure things out.
• Don’t make flexible where you need it (lose). It might require some serious refactoring in the future – it’s not something you can call cost effective.
Predict Success or Adapt to Change?
Those who cannot predict success must be able to adapt quickly to changes – up to and including radically changing the philosophy of their software product (which is also quite common for startups). One of the best sources of help here is your software team – the project manager and developers. Their mix of experience and enthusiasm can help you understand where and how changeability should be applied with greater chance of success – especially if you’ve developed roughly similar products in the past.
The developing technology and mobile market will not allow a mobile startup to plan things and launch the product in one year. Even less time is enough to make the product irrelevant. Computers used to be for limited use, there were fewer hardware options, and desktop versions of Windows could last for years.
Now the power of a computer can be held in the palm of your hand, and major mobile platform updates are released at least once a year, while minor ones are about four times more frequent. Our devices have become more environmentally sensitive – they have cameras, accelerometers, GPS, connectivity, augmented reality and more. If you can’t adapt, you lose.
Who can afford to roll out the mobile product as planned in a year? Definitely not startups. Only large, stable companies that occupy hardly any different market segments can afford that. For example software for inventory management. Well, it’s changing, but to a much lesser extent than such software categories as gaming and entertainment. Another example is an app that displays a public transport map. Adding a new subway line or station is unlikely to cause any problems.
In contrast, there are social networks. User behavior can be broadly categorized, but in general it’s pretty unpredictable to know what’s going to hit the mark. Just think of the ideas of Twitter (many people doubted at the time that limiting blog posts to 140 characters would attract people) and Instagram (the earliest versions were very, very bad).
Use the experience of your developers to achieve the first option. A classic mobile startup searches the market and reacts quickly to user feedback. As far as developers’ work goes, building and maintaining software is still an art for many reasons – and finding the balance between modifiable and inexpensive is one of them.