Flexible Deliverables

Times change, desires change, we’re well aware of that, and prepare for it by expecting it.

The old cliche goes “the only constant is change”. Software development projects are certainly not an exception. Software is essentially a living, breathing organism, at least until it’s all grown up (and ready to retire). If it’s built well, people will want to change it, because they’ll want it to do more and more for them. If it’s built poorly, people will want to change it, because it doesn’t do what they want it to do.

We like to make the kind of software that people keep wanting to add more and more to, because that means it’s successful software. If someone likes using it, they’re inevitably going to want it to do more for them. If it gets to the point where they don’t want it to do anything else, then someone is going to commoditize it and it’ll go the way of pork bellies, which to us isn’t a lot of fun.

In order for software to be healthy enough to grow, it has to be created from the inside out with that in mind. Through a combination of learning, foresight and experience, we are able to build your software so that:

  1. You are not locked into a frozen set of features
  2. Your system can grow without having to gut it and start over again

We know that people will want to change the software, so we work in short cycles with flexible plans. We believe in frequent releases of the software we develop, whether internal (for review by decision makers) or external (to keep the good stuff going out to users). We orient our whole development process around that, because:

  1. We know it shows you results
  2. It allows us to know that we’re doing the right thing
  3. It gets new cool stuff into your user’s hands more often

We are not going to go into a dark corner and write code for 6 months and then come out and say “what do you think, hope you like it, changing it would be a real b**ch”.

In our experience, the code that we develop lives a long time, because flexibility and foresight are used in the design. To be frank, the most likely time for something we create to be thrown away for a complete redo is when some technology has come along that just makes sense to leap to and there’s no way to just do a straight (and good) conversion. Just letting you know, in case you think we’re starting to sound like Shamans.

If you’d like to find out more about why flexible deliverables make for successful software, please contact us.