This case study is an abstract of a PHP/MySQL project I worked on quite a while back in my history as a developer; Essentially, a management system that was built utilizing a database front-end generator needed substantial updates. I’d like to share my experiences with it, and caution anybody looking to utilize a front-end generator to think about the longer-term viability of such projects.
Basically, why you should hire a developer.
Essentially, a database front-end generator will automate the process of creating the user-interface for a database. This can be anything from a simple set of excel-like tables allowing someone to read the data easily while minimizing development time, or even building larger-scale user-interfaces for more complex systems that will store, manipulate, and allow advanced querying of data by non-developers.
If you’ve got limited developer experience, limited time, or a limited budget, utilizing something like a database front-end generator can seem like a lifesaver. A good one will spit out reliable, semantic code that will run fast and be secure, reducing overhead in the production. This can be great for quick proof-of-concept apps, crafting a simple method for querying an existing database for non-production systems, or even helping low-budget teams add to their capabilities for web clients.
When you build a database front-end from scratch, you’re building something specific to the needs of the data, and nothing more. This reduces the potential points of failure, allows for the code to be easily modified in the future (assuming it is developed correctly), and can help with data security, stability, and speed of access.
I was tasked with making significant updates to a system that was built utilizing a front-end generator. I don’t think the original developers intended for it to last as long as it had, nor would they have considered someone needing to modify the code by hand, rather than utilizing the existing front-end generator.
The project, by the time it had reached me, had been through multiple developers. Thankfully, at least one person before me had been considerate enough to attempt to document some of the code; generators aren’t always clear as to what does what when doing commenting (if they add comments at all).
As well, generators don’t always follow traditional human-friendly code structures. They don’t have to. I’m not just referring to variable names (this one actually did fairly well), but also splitting up reusable code in a semantic way, and ensuring that the code references sprinkled throughout actually made sense.
This one did things “backwards” (I would share sample code, but I wouldn’t feel right since it isn’t mine to share), essentially duplicating libraries in such a way as to balloon the entire code base by a significant factor, and also stored some data in a way that either would’ve required refactoring the database and front end on a major level depending on future expansion.
A prime example I encountered in this was storing nearly every array in serialized format, when separate tables would’ve created a much more stable and accessible code base.
When I talked with previous developers who had helped maintain the code base, they all essentially had the same thing to say.. “Good luck.”
It took me days to read through the code to understand the logic created by the database front-end generator. Even then, there was a lot of “I can’t even fathom why this works, but it does.”
While database front-end code generators can seem like a savior, be careful what you wish for. Saving time on the initial build is great, but if you don’t account for future expansion, you could be destined to hours upon hours of cursing and headaches trying to maintain the aging platform.
A code generator isn’t capable of understanding intent. Developers (hopefully) can. While the time spent on a new project can be daunting, utilizing established practices, planning, and well-supported libraries will save you time and money in the long run.