For the past couple of weeks, I was experiencing a sort of separation anxiety. All work on MEDtrip had stopped, and what would happen next was still vague and uncertain. The last code I did for the app was to place a modal that said:
This legacy site no longer reflects the focus of our business.
It does show the quality of our work but not our post-pivot market or product.
If you would like information about our new direction, please contact our CEO, Richard Coyte, at richard.coyte@medtrip.com.
This was heartbreaking. I have worked on MEDtrip for more than a year straight, and the technologies I’ve learned to use in MEDtrip are all I am familiar with. From the days and months that I spent troubleshooting and implementing new features, I can say I’ve attained some mastery of this project.
The Craft and Construction behind MEDtrip
For those unfamiliar with MEDtrip, it is Chromedia’s four-year long in-house project, designed and implemented by none other than our senior developers. Since it was designed and implemented more than four years ago (and given the current turnover of software and technologies), MEDtrip can be considered quite “old.” And its technologies are all I know — Symfony 2 and Backbone JS.
So I am faced with a dilemma: what happens to the project post-pivot? What technologies will be used? What do I need to know to fulfill my role for the new MEDtrip?
When I started working on MEDtrip, it wasn’t until the fourth month that I felt I finally became productive. Symfony was a non-opinionated framework, and for a non-university-schooled beginner like me, it was very difficult to learn. Symfony was a culmination of the advances in PHP framework design. Four years ago, it was the bomb. It addressed many issues encountered by previous PHP frameworks, and its core components had been used as part of the foundation for the development of other frameworks.
For those not familiar with developers’ jargon, ‘non-opinionated’ means there are minimal to no set of conventions in the code design and implementation. Everything is laboriously defined, and components are individually selected and included in the grand scheme of things. Opinionated frameworks, on the other hand, have a ready-made set of components, coding conventions, folder and storage systems, all ready to be used upon installation.
In a construction analogy, Symfony gives you the building blocks for creating the scaffolding which you use to build a house. But with an opinionated framework, the scaffolding is already created. You go straight to building the house with ready-made tools and materials.
Symfony is just half of the story. There was also this back-breaking Backbone JS. As a noob in Javascript, I was yet again faced with the daunting task of figuring out old code and implementing new features using Backbone and Javascript.
If Symfony was used to create the shape, foundation, parts, and building blocks of the house, Javascript and Backbone were used for the façade, the shape and design of windows and doors, the general functionality of things, and their interaction with the people using them and living in the house. It was an entirely new ballgame! And, you guessed it, Backbone was non-opinionated.
An Opinion on Opinionated VS Non-opinionated
So while I was working my ass off in just trying to understand previous features and code, let alone work and implement new ones, I couldn’t help but think: why go through all the trouble in setting things up, defining conventions, and creating tools and systems, when ready-made stuff was readily available and could be used instead? Were these senior developers masochists or something? Were the people here really that good that they opted to create everything from scratch?
Then as I went along discovering and learning things, some important realizations came to me. If you wanted a house of any shape and size, with all sorts of nooks and crannies, and maybe even secret passages that only you could think about, then you couldn’t use a scaffolding with a predefined shape and size! If you wanted this house to be equipped with security features that only you knew about, again, you couldn’t use a framework that dictated a generic placement of the windows and doors. If you wanted to change the kitchen or add a swimming pool later on, the predefined size and shape of the ready-made framework couldn’t accommodate any of your whimsical wishes! Or maybe you could, but crazy enough, it wouldn’t be as easy as working with Symfony! The senior developers weren’t crazy after all.
Building Towards the Future
As I developed my skills sawing and hammering and putting stuff up, I came to love the technologies I initially detested. I began to enjoy figuring things out, finding means to implement new features, and troubleshooting bugs. My productivity finally caught up. My confidence soared, and I also began to think beyond the MEDtrip app. I began to imagine things I could do with the tools I now had.
Given the hardship I encountered in learning Symfony and Backbone, I realized how easy it is now to learn new technologies. I can even laugh at some currently popular framework and consider their methodologies as clerical stuff. I am now unafraid to face and learn whatever new technology is necessary for me to contribute and do my part.
Thus can I confidently say that the old MEDtrip has not been in vain. From a developer’s standpoint, its fruits are to be reaped in the years to come — all because these “crazy” senior devs definitely knew their craft. So while I say farewell to the old app which I have grown to love, I can greet the future wholeheartedly, ready to build on the MEDtrip experience.
