Why software is never finished

You use an app every day and know your way around it like the back of your hand, and then one day it looks different. Your brain freezes for a second, and you go hunting again for the one button that does what you want.

Most websites and mobile apps launch as a first version, and they keep changing after that. The Nature of Software Development explains why with a car example, and we like it enough to borrow it.

Say you are inventing the first car in the world. You want something that gets you from Point A to Point B faster than walking, so you take a board and attach two wheels underneath it for speed.

That works until you are zooming down the highway and realise you also want it to go in the direction you choose. You did not think about steering at the start, because all you thought you needed was to get from Point A to Point B. So you add handlebars, and now you have something that looks like a scooter.

You keep going, finding the next thing to improve and iterating on the vehicle until it solves your problem and a few more.

Software gets built the same way. You create, test, discover something you need that you did not think of before, create again and test again, and the cycle goes on until you have something close enough to solve the problem.

That is the nature of software development, and it means the product keeps changing. Along the way, developers fix issues in the app, change current features after users validate them, and add features the client realises they need. The timeline set at the start of a project is often not the timeline the product needs to reach a "perfect" state, if there is even such a thing.

After 10 years of building software with clients, we adapted our development methodology to follow the agile approach.

What agile means

According to cprime.com, agile software development covers methodologies built on iterative development, where requirements and solutions evolve and improve through collaboration. The approach expects changes and plans for them.

Why we use agile

We believe an app does its job when its users can do what they installed it to do.

So we deliver the product in versions, one increment at a time, rather than all at once by a fixed deadline, and we get early feedback on how it works for its users. What we learn about serving those users better goes into the next cycle of development.

That way our team, and our clients most of all, do not put a lot of resources into building something for a long time before users get their hands on it, only to find out later that most of what we built does not help.

How we measure effort

On Symph projects we measure effort in blocks and sprints. 1 block is 3 hours of design or development work. A sprint is 20 blocks of design or development work, which is 2 weeks, or 10 working days at 2 blocks per day per person.

How the process goes

First, we meet with you to learn what business goal the app is meant to reach. That gives us a clear picture of how the app should work by the time it launches.

Once we have that, we ask about your idea for the app, which features would best solve your problem and how they should work together. We rank that list by what is most essential and work through it from the top down.

One sprint is one round of our development team completing a set of features or iterations. At the end of every sprint we show you a version of the app to test, and your feedback is what we take into the next sprint.

Besides regular meetings to demo the updated app, we give you access to the development versions of the project, so you can explore them in real time and see how the work is going.

How fast we go

That depends on how fast you want to go. Our speed in delivering features depends mostly on how many people you allocate to each sprint, and more people means faster progress.

If you want to work with us this way, talk to us.