Software development is a creative endeavor, which makes it risky. It’s rare to know exactly what needs to be developed when the project begins. So decisions are made on the fly or modified when necessary, users give feedback that changes how a feature works, and new features come to mind midway through development. This is all great, as it will lead to a better end product.
However, this adaptation to change does not come without a cost. The new feature you realized you needed will often mean an existing feature needs to get axed. The user feedback you received means something already developed needs to be tossed out or modified to work in a way users expect. The decision you changed your mind about needs to get communicated out to the team and properly tracked.
Handling this change properly is a tough job when it goes across one platform. But when developing for multiple platforms simultaneously, the cost of those decisions is magnified significantly. This has been a problem that we wanted to address to both allow for change while not having to punish our clients for making these new decisions.
What we have been experimenting with lately is starting development on one platform, letting it get sufficiently ahead, and then beginning development on the remaining platforms. This significantly cuts the cost of the changes and eases the communication overhead of handling multiple platforms simultaneously.
In some cases, we have finished the entire app on one platform before moving on to the next platforms. In other cases, we let one platform lead the way by a number of weeks and then begin development on the remaining platforms.
We are early in our experimentation, but so far we have noted significant increases in both quality of apps, and happiness of our clients and development team. Change is needed but change is hard. When we can limit the amount of change, it eases pressure on both sides and leads to a higher quality end product.
And since quality is our focus, we’re happy with that result!
