A philosophical guide to writing custom software for clients


A philosophical guide to writing custom software for clients

Dont introduce new technology if you don’t have to

One difference between what we do and more traditional solutions designers is that we are not interested in selling you an infrastructure that you don’t understand. Wherever possible we will use the technology you already have and are familiar with and therefore likely to have in-house support. If you already have have internal web applications written in PHP, we won’t try and introduce Node or .NET. If you already have Microsoft SQL we won’t build our solutions in Postgres, Mongo or MySql (unless you want us to!)

Dont hide configuration in the code

Although it is easier to write the code so that file locations and names are hard coded or in a definition block at the top of the program, these applications are designed to be written once and survive changes in the organisational IT rules. By putting values into a configuration file or table, you can make it easier for the internal support team to understand what is happening and how to copy or move the application or it’s files and the permissions it relies on. It also means that the values can be changed without having to edit the main application

Separate logic and data

Typically a lot of the applications we write are in desktop software like Access or Excel. By default the logic lives in the same file as the data, whether that be tables or spreadsheets. There are two problems with this: First these files can be copied and you end up with multiple copies of the same application. This means that when you find an error, you now have to fix it in multiple places and you might not know which version of the code is being run in each copy. Second, when you want to upgrade the application, you can’t just take the the development copy with the new code and overwrite the original, because the development copy will not have the most current data

Don’t assume anything

When writing code in desktop applications, especially Excel, we can’t take anything for granted. Workshhets get renamed, columns get moved, data may not be there or in the wrong format. Compensate where you can and make sure that errors are handled gracefully whereever possible

Put everything into source code control

SCC is a technique for ensuring that different versions of your code are stored for posterity; you can compare one version with another and see how the code has changed over time. If you are having issues, SCC is a critical component to allow you to go back to a previous version. One of the reasons we can be so competitive on price is that we operate a joint-ip policy. You get a full copy of the code that we write for you to do what you want with it within your organisation; if you modify the code and ‘break’ it then we can compare that to the version we gave you and/or the most recent version and identify where it is likely to have gone wrong.

Documentation at three levels

We believe that any application of a decent size needs documentation for three different audiences: the WHAT for the users running the application, the HOW for the 2nd and 3rd line support teams and finally the WHY for the analysts and architects. All applications that are more than just an Excel workbook (and even some of those!) come with comprehensive documentation.

About the author

Aaron administrator

Leave a Reply