7. Build in configurability
2. Handle multiple languages
3. Compile scripts and styles
4. Abstract data by type
The more parameters a software developer can abstract from the source code, the more maintainable an application will be. So when we developed the ElseApps Framework we took great care to avoid hard-coded values. Foundational values – the base URL, relative paths to directories – are stored in a config file, but we tried to expose other variables through the interface itself, with the intention of making future tweaks as trivial as possible.
We knew from experience that even those values a client believes to be immutable will inevitably become candidates for change over time. The type of files an applicant can upload, the number of days until an overdue report is classed as urgent, the resize trigger for uploaded images … these are among the many settings we expose through EAF’s configuration pages.
But EAF goes a lot further than that.
All the web application’s pages are configured within the application itself, including role-based permissions, references for contextual help, menu positions and the class name to be invoked.
In the same way, blocks of text content within the web application, email templates, reference data and even the forms themselves are editable within the application. Over time this greatly reduces the cost of ownership, as many changes can be made without touching any code.
Individual users also benefit from this focus on configurability. Every user can personalise commonly used formats, and see their preferences applied to all data.
Interestingly, this was one feature we had difficulty selling: some clients initially felt they should be able to dictate formats for all users. So far, however, letting clients determine the default formats seemed to have allayed this desire.
In the final lesson from EAF we’ll look at the ways in which we designed the framework to deliver more than users expect.