There I was, fairly new to a company, and asked to take the reigns of a project because of limited developer resources. This new project, was essentially, to design and implement a brand new web application to store and view primary geo-technical data. Everyone else was committed to another project, and although I didn’t have the expertise to do this on my own, I was the only one around available for the the task at hand. It was a bit of a departure, as I was originally working on an an existing C++/Qt codebase with other developers. There were many obstacles from the very beginning, including architectural design decisions, unclear specifications and requirements, and limited experience for the needed project.

The dizzying highs:

Our first big challenge was designing what the system should look like, based on the requirements that were somewhat ambiguous at the time. Furthermore, one of the desires of the system was for the user to have complete freedom in designing the geological constructs to store data. This meant, we would have no idea what a “something” would look like until the user created it, and what additional attributes it may have. There was talk of creating database tables as needed, for each new construct. Basically, the user would be a god in the system (or dog, I forget which). This would be problematic. How does one query a database when you have no idea what it looks like? Furthermore, how does a DBA maintain it? How would you adapt software to adapt to the ever-changing data-store?

Our first conclusion was creating tables dynamically, for an unknown number of constructs, would be messy, and likely suicidal. There was a DB paradigm out there that we could possibly use, as a RDBMS didn’t seem ideal for our needs. It was No-SQL. We had focused a little on learning MongoDB and had high hopes for using it (plus, it’s webscale), but alas, we had no in-house expertise and the timeline for project completion didn’t leave much for gambling on something we knew little about. As an alternative, our database team suggested we use an EAV database design pattern for storing dynamic data within a RDBMS. The only caveat would be we would need to limit the user from creating dynamic constructs, and give them pre-built ones, but general enough so they could design their own templates on top of our core. This was an accepted solution, so we moved forward.

The terrifying lows:

Since another web product the company was committed to was already built using PHP and various Microsoft technologies (namely, IIS and SQL Server) due to client imposed restrictions, the trend was that we would develop this new web application with the same technologies.

Using PHP, and the Microsoft colors of the rainbow is not particularly advantageous. They are technologies that do not compliment each other. And as a result, there is very little help and documentation out there in the event you hit a wall. Stick to a solution stack that works well together, like LAMP (Linux, Apache, MySQL, PHP) or if Microsoft is your preference, well ASP.NET would be preferable over PHP.

And finally, a client should not be dictating what your software stack is for a cloud-based product, as along as it delivers on the required use-cases. But that is an argument for a another time.

The creamy middles:

Development resources were something that was lacking on this project. Others assisted where they could, but they were primarily assigned to other projects, and so much of the day-to-day coding was done by myself. Now the main issue with this, was that I was not a web developer by trade, however, due to the circumstances, I became one. I learned as much as I could, and did the best with the what skills I had and what I could learn from the only other web developer in the company. I learned a great deal, which is one of the pluses when thrown into a situation as this, but most days I felt like this. Also, I am certain that had there been more experienced web developers throughout the development of the project, certain steps could have been achieved more quickly.

In the end, it turned out better than I had expected, but there is still much to be done in the next phases of QA, deployment, and maintenance.