Software is a little like sausage: everyone likes it, but no one really wants to know how it’s made. The truth — much like with sausage — is that quality software comes from quality ingredients that are treated with care and attention. In my many years as a developer at Minemax, I’ve learned a lot about the realities of software and how it’s created. Sure, I went to university and read all the books, but there are many flavours of development out there, and each one is rooted in the needs of its industry and customers. I’d like to take you on a short journey through development at Minemax to give you an idea of what makes the software on your desktop happen.

But Daddy, I want a pony!

At Minemax, we make software. This is our focus. We have a small number of products with long life-spans. That is, we don’t just build a product, release it, and then ignore it. Each of our products is constantly undergoing improvement, not just to fix issues, but to add new features. These features are driven by customer requirements and needs. Sometimes this happens in the form of direct requests, but more often it’s through the careful observation of support tickets and other interactions with a large number of customers. By identifying patterns and applying our expertise, we’re able to anticipate what features would be most useful.

There has to be a better way

A recent example of this occurred when, over the period of a few months, we noticed several Minemax Scheduler customers using “fake” pits and pit-to-pit precedences to model capital development precedences. This allowed them to avoid running many scenarios (sometimes hundreds), but the result was incredibly complicated, and not particularly efficient due to the abstractions involved. After observing this, I felt that there had to be a better solution. It had to be modelled properly to make it efficient, and it had to be easy enough for people to use. I also felt that there were other capital modelling details that could be added. I spent a few days on the train to and from the office, scribbling math and playing with ideas. Finally, I had something workable.

Polish it until it shines

It was now time to bring the idea to the rest of the company. At Minemax, everyone is involved with the direction of products: developers, mining engineers, software testers, support staff, and managers. I described my concept of having Capex  modelled as option-sets, with precedences between them. After presenting my ideas, I gained invaluable feedback as to what would and wouldn’t work. Some aspects were deemed unnecessary and over-complicated, while others were missing. The way in which sets were included needed to be optional. There was also a clear need to incorporate multiple instances of each capex to simplify modelling unit-based resources such as trucking. After some changes to the math, I sketched up some simple user interfaces and began implementing a prototype. A software prototype is a version of the software that is never released. It allows us to prove that something works, and then build, evaluate, and iterate on ideas as quickly as possible. Sometimes we make prototypes that turn out to be dead ends, and we need to discover this as quickly as possible to avoid wasting time. More often, however, we make prototypes that turn out to be promising, and we want to polish them until they shine.

Share the knowledge

While working on the prototypes, we chose to share some of this research and work in the form of a published paper and presentation at a conference (AusIMM SMP 2014). While this does take some time, we believe strongly in contributing back to the industry. It also provided an opportunity to get invaluable feedback from potential users in the industry. Precedences between multiple instances of a capex needed to “count” to allow modelling concepts such as truck rebuilds. There were also some minor revisions to the language used to describe the new features to ensure that their purposes and functions were clear. This additional feedback allowed us to come to a final set of features, and informed our user interface design to ensure that it was as simple and intuitive to use as possible. We were then able to quickly finish the implementation, and to complete reports, ensuring that the results were visible and understandable. With a little more work updating the installers, the development work was almost done.

Lather, rinse, repeat

This “final” version is not the end of the story. Before we’re able to release software to be used by industry, we want to make sure that it is as robust as possible. Our in-house software tester manages testing to ensure that results are correct and the software is as bug free as possible. Acceptance testing is also performed by our in-house mining engineers, to ensure that the way that the software works makes sense to mining engineers. Any issues discovered during this testing are fed back to developers, who make the required changes. The software is then rebuilt, and goes back for more testing. This loop repeats until the software is deemed ready to release. Unlike many other software houses, Minemax does not release on deadlines; rather, we choose to release software when it is ready.

How do I use this?

Releasing a new version of the software means updating documentation. This is particularly important when new features are added, as existing customers will need to know what’s changed. While testing is occurring, the documentation is updated. User manuals are updated to include any new features and changes. We also update the training, where appropriate. Basic training is updated for most changes, and any advanced features are added to our advanced training. This often involves building new exercises. In this case, some old exercises were replaced with simpler techniques based on the new modelling features. Once updated, all documentation is proof-read and checked by mining engineers. Updated user manuals are then included in the installers for the release.

Ship it

So now all the work is done, we’re ready to ship? Not quite; as this is a major new feature set, many people are anticipating the release. It’s important that we let them know when it’s available, and what’s changed. That means that there’s still the website to update, update notifications to prepare, and email and news campaigns to organise. For some releases, we also prepare a quick demonstration video to show new and existing customers how a new feature works. When everything is ready, and everyone has signed off on their various responsibilities, we release the software for you and everyone else to download.

Is this the end?

So now the software is released, but it’s still not the end of the story. Even when a feature is complete, it isn’t finished with. Sometimes customers will need assistance making use of new features, so our support team are ready to help them. Further feedback, bug fixes, and new ideas will continue to focus and improve released features. After all that, there’s always the next set of features to consider and begin building. We never stop trying to make the software bigger, better, and tastier for the people using it every day.

Would you like to know more?

More information about the Capex modelling features mentioned may be found in this article on Truck Purchase and Rebuild. Maintained Minemax Scheduler customer? Download the latest version now to see what other new features we’ve added. Do you have some great ideas that you’d like to see in Minemax software? Let us know.