A “Digital Experience Platform” is basically interactive software where data can be maintained, not much different from a regular application. But it’s a marketing term, because software also needs to be sold. One such DXP I loved working on was for OPPLE. They are a brand of lighting products and have over 14000 different items.
My contributions were taking ownership of their catalog generator tool and maintaining the data of their products in Drupal on their website.
OPPLE Catalog Generator
All the data was supplied through an external API by Compano and through an uploaded XML file. This data had to be parsed and converged into a logical structure so that products and product families were matched along with their features, photographs, accessoires, dimensional drawings, sensor diagrams and more. And all data is multilingual. And of course data had to be exchanged through excel files for pricelists and tender texts. Data was used interchangably between different tools and websites.
The catalog generator makes use of the Drupal platform as an intranet portal where thousands of PDF’s could be automatically generated in a single batch. The customer only has to alter the data and the layouts and appropriate sections appear.
Legacy code
This project was handed to me as a monolithic source, with only 1 PHP file containing all the rendering logic and handling exceptions (as in, many products had their own unique, exceptional attributes). This was a project that had outgrown itself and was hard to scale further due to the current structure. I had to improve the code base, while retaining the legacy functions. But because everything was so tightly coupled I had to make sure a change did not break functionality elsewhere. The key is to write new code and provide “safety nets” for older code.
A common misconception is to think by creating quick code, is easy gain. Not much effort, just copy and paste the existing logic and adjust it a bit. Then put it in the same file, no need to document it. But by building up Technical Dept, you will either leave this code behind or you will forget how everything works. Making code scalable, is essential. Even for “small” or “temporary” projects. Do not take shortcuts, thinking it will save time or meet the deadline.
Improvement
Restructuring code built as such requires mostly patience. You cannot instantly restart everything, as this tool is used in production. You cannot create a new architecture complete with diagrams, there is currently no time. It is not the only project I work on, there are 20 other projects that also require attention. Instead, I started by moving functions around every time I worked on a new feature for the tool. Dedicating existing functions to separate module files was the start. Creating object-oriented code for new features was the next step. Applying unit tests came next. As long as a new feature request did not exceed in time, it could be slowly prepared to grow by having prework done every time.
Eventually, it became a tool with composed logic, making future maintenance and feature requests a lot more simple.
Moving forward with a structured tool, I am proud to have collaborated on this project and improved upon it. But when I was no longer working on this project, it got outsourced or abandoned. To me, this really was a project that was handed down from developer to developer and code just got copied and pasted. There were so many lines of code confined within if-statements, a lot of duplicate code. I am not surprised this project was abandoned and sadly I put many hours of unpaid work into this project to make it better, but it also became complexer. Again, to me it means that taking time beforehand to desing and architecture the software would make more of a difference. Not, here is the code, add this feature, you have 5 hours according to Jira.