Before working for a construction software company, I had very little appreciation of the complexities involved in some of the changes that I thought would have been fairly straightforward. And so my software learning curve began.

It is impossible to produce systems of any size which do not need to be changed. Once software is put to use, new requirements emerge, construction software development evolves and existing requirements change as the business running that software changes. Parts of the software may have to be modified to correct errors that are found in operation, improve its performance or other non-functional characteristics. All of this means that, after delivery, software systems always evolve in response to demands for change.

First point of contact for our customers is our support team; they help to define which category the problem they are experiencing is in. These fall into the following:

1) Maintenance to repair software faults

These could include rectifying coding errors which is usually fairly straightforward and inexpensive. If the coding relates to design errors this is where we can see further complexities and costs added to the process.

2) Maintenance to adapt the software to a different operating environment

This type of maintenance is required when some aspect of the system’s environment, such as the hardware, the platform operating system or other support software changes. The application system must be modified to adapt it to cope with these environmental changes.

3) Maintenance to add to or modify the system’s functionality

This type of maintenance is necessary when the system requirements change in response to organisational or client requests.

The scale of the changes required to the software is often much greater than for the other types of maintenance. This is why, at BuilderStorm, we have to plan any of these requests with care as the impact on resource and possible functionality is critical.

This is where I revert back to my naive thinking before I knew all of this and realise, it really isn’t just adding a button!

BuilderStorm software is forever adapting to client requests and software requirements but we do have to weigh up the implications as every change we make impacts each client and, furthermore, could impact our business strategy and selling power in the market.

As part of the Support to Development process, we look at the root cause of the queries that come in and decide whether or not anything can be prevented for the future. For example:

1) Training process/implementation

We look at whether any queries coming in could be better handled at training an implementation stage and adapt the program accordingly.

2) Manual Testing

Once a bug has been confirmed and identified in the system, either by ourselves or a client, we carry out a manual test case to make sure that these bugs do not occur again, and if in the rare case a similar one does, we are quick to fix.

3) Sales and Marketing

Looking at the sales process and handover into the business to make sure that we are being clear with all our customers through the end to end process, and utilising every feature to best complement the customer’s processes.

We have a continuous feedback process internally to make sure we change processes where needed, prioritise our workloads dependent on impact to clients and develop areas of the system which we feel will make the software even more market leading.

So when I get asked the question, ‘Can’t you just change that button?’, I try and share my learning curve to demonstrate the complexities that construction software development brings to a business from a service, cost and strategy perspective. If you’d like to discuss how Builderstorn can help your business develop, please don’t hesitate to get in touch.