Writing software is hard. Really hard.
As software developers we need to consider how things work and also how things might break – like users typing letters when they should be typing numbers.
And we need to test. A lot. There is no such things as “too much testing”.
In fact, we often end up writing 2 programs – the original program – and the testing program. (and no we don’t write tests for the testing programs lol)
So you can see there’s a lot involved.
And it’s still written by humans for the most part, and so sometimes mistakes (“bugs”) creep in – we are only human after all.
And this is where things get interesting from your point of view.
Consider this: you’ve commissioned a company to build you some software and you chose what you thought was the best option: Time and Materials.
But now there are some bugs because developers = human (remember?) so who pays to fix them?
Well… you do, of course.
You specified Time and Materials so if they got finished early you saved but if the project runs over you pay. It’s only fair…
Which is why, at insilico, we only do fixed price work.
We know what we’re doing and we tell you up front what it will cost, and if you’re happy with that price we’ll do business.
And if we find any bugs within the first 30 days of live operations, we fix them for free.
And if you’re on a service agreement with us you never pay for bug fixes. Ever. Period.
Because, as I said before, bugs happen – even though there are no moving parts – things “break”.
But Local Software Development is Expensive…
Well it depends…
If you want to automate something you do once a year that costs you a whole day to do then it probably is.
But if your team of 10 have a thing they do daily that takes 30 minutes then maybe not.
Let’s do the maths: 10 people x 0.5 hours x $25/hr x 5 days x 5 weeks = $32,500 in hard costs.
If you can solve this problem for even $30,000, you break even the first year but then you’re ahead!
…And Outsourcing is Cheaper
Yes, we hear this often when people outsource their software requirements to the subcontinent (India, the Philippines, etc.)
And those folks, bless them, will do exactly what you tell them to do and build exactly what you tell them to build.
Nothing more. Nothing less.
And so when you say something like “I thought you’d implement the best way to do this”, they may not.
Typically these folks are a few steps behind best practices.
No revision control systems.
No structured upgrade processes.
No database migrations.
It’s all done by hand because labour is cheap but it’s the manual handling where most of the errors occur.
So now you’re not only the client but also the project manager in an area where you have an understanding but are perhaps not the expert…
Anyway, You Said “software has no moving parts” – How Can it Break?
This is a real and valid question: how can it break?
And the answer is two-fold.
Firstly, if software breaks it was possibly always broken – you just never tried that particular feature before.
You’ll have seen this when you try some fancy new or previously undiscovered feature of a program like Microsoft Word.
Word has worked flawlessly doing all the normal things you use it for but then you try something fancy.
It might be Word Art or different page layouts or any number of cool things Word does and >>>BOOM<<< suddenly all your hard work is gone.
The bug was always there – it just that feature didn’t get its fair share of testing.
The second possibility is the new “shifting sands” that everything is now built on.
In the “old days”, your operating system upgrade was a major exercise and not undertaken lightly.
Backups galore were the order of the day and your office IT department were all on super-standby in case anything went wrong.
These days we have “Update Tuesday” – every Tuesday there is some update or another from Microsoft or one of the other vendors and consequently your previously rock-solid work computer suddenly becomes as flaky as!!!!
And then your apps break!
And there is sadness and anger and frustration (yes, I’ve been there…)
The Solution (and Our Guarantee)
It’s not advisable to turn off upgrades – this particular “cure” is worse than the “disease” it leaves you with; a computer without updates is more prone to hackers, etc.
So what do you do instead?
Well, we solved that problem for our clients very simply. We guarantee our software to be defect free or we fix it – at no charge.
In the past we did specify a “use-by” date for our guarantee simply because if you report a bug 6 months down the track, we’ve got to put down our current projects and pick up yours and all this takes time.
So we introduced Software Service Agreements with every system we build so now you have insurance to cover the cost if you find any bugs at any time. Ever.
And we’ll even help you transition from one version of a software package to another such as upgrading Microsoft Office, for example.
So How Can We Offer Such an Amazing Guarantee?
Well for starters,we work in several different domains: development, (in-house) test, (user acceptance) test and live/production.
By working in this fashion, we have increased our chances of finding bugs before they even reach you.
We also try to automate our testing as much as possible. There are some very cool testing tools for some software development but, sadly, not for everything.
We’ve built what we can for the tools we use but sometimes there are limitations.
And for those cases, we test manually but there are still times when our testing doesn’t quite match the real world and this is usually when things go wrong.
So then we encourage our clients to have a test system as well as a live system.
We roll out to “test” and they can give our software a hammerin’ for as long as they like.
And when they’re happy, we roll out to “live” and our software is now in production and life just levelled up.
But Paul, What If I Need You to Make Changes, or Add New Features?
insilico uses a number of processes we’ve copied from the leaders in software development.
Whenever a database change is required, we use ‘migrations’ to make the change, ‘bootstrap’ files to pre-load data and ‘fixture’ files for testing those tricky situations.
We also use an oddly named but extremely powerful testing language called ‘Cucumber’ (I know, right!)
‘Cucumber’ is a “process definition language” that lives somewhere between English and an abstract pseudo-programming language.
But with just a little training you can easily read and understand it, and we use this as the basis for our automated testing.
And if we can’t automate the testing then we manually work through the steps.
So at any time, we know we’ve done our best work so as to deliver the best software to you.
And if we did miss something, then there’s always our guarantee to fall back on.
So do you have some software/system requirements?
Do your staff waste time doing things that could be automated?
Put us to the test!
Work with me, right this second – just pick up the phone and call 08 9200 4431.
If you get voice mail then I’m on-site with clients so please leave a message with your name, company and best contact number and I will call you back as soon as I’m free.