In all types of computer programming, be it web or desktop development, most developers don’t want to reinvent the wheel. Why spend your time and effort writing some code that someone else has already written? The code that is available ranges from small jQuery plugins, right up to full platforms which enable full applications to be built on-top of them. I refer to them as “black boxes”.
Essentially you input some data at one side and get some different data out on the other side. In some cases you know what the code is doing and how it works. You are just using it to save time. In other cases (which I suspect are more common), though, you may have no idea what the code does, or how it works. All you are interested in is outputting the code you want.
Just because these black boxes are available does not necessarily mean they should be used. Using some code that you don’t fully understand is often fine. It can save time and effort. But sometimes, it forces you into using programming conventions and methods that may not be ideal for your project.
Look inside the black box
During one job for a client, I was faced with a choice: build on top of an existing platform, a black box, or build a bespoke system. The project was for a recruitment consultancy that wanted a system and website. On the front end they wanted the ability to advertise jobs nd receive applications, while on the backend, they wanted full Customer Relationship Management functionality. Simply, they wanted a combined CMS and CRM system combined which would allow them to refine their business practices.
As with most development projects, the client wanted the system working quickly. It was agreed to build an MVP (Minimum Viable Product) first. This meant it would be ready to use in a shorter time, had an easier-to-stomach payment schedule, and the potential for new functionality to be designed and implemented on an ongoing basis. This meant there was an initial list of functionality that had to be built, with plans to add more later.
The two main requirements for the server were these:
- It needed to work on a variety of devices with unknown screen size. These devices could not be required to use any specific app.
- It could not not be dependent on any one static server in some back office.
They wanted a web app.
Analysing some black boxes
In the planning stages of the project, many popular web-based platforms were considered and analyzed to see if they would be a good starting point for the system. The main ones considered were:
Each would have been a good foundation for building the new system, but none were perfect.
Perch, being the smallest, was not really designed for what I wanted to do. It would have required some intense modification to make it work right. This would have been my first use of the CMS and it was a total black box to me. Taking the time to learn how it worked would not have been a good use of my time, nor an expense the client would have been happy to cover.
Drupal offered the ability to make it work exactly as I wanted, but the user interface was lacking; the client would have struggled with it. I have a pretty good understanding of how the system works, and could predict some issues with future functionality. The programming conventions used by Drupal would have meant a lot more time and effort was needed in the future.
WordPress was a good balance. I know exactly how it works, I could make it work exactly as I wanted, and it has a good user interface. There is also a massive existing repository of plugins that could be taken advantage of. However, these are all just small black boxes. As with Perch, taking the time to learn how they worked was not really an option; and having a system where I know how some parts of it work, but not others, was not something I wanted.
After assessing each platform, and taking into account the current scope of the project, plus any future developments, I made the decision to build the system from the ground up.
A transparent box
Many developers will argue that starting from scratch is a waste of time and effort. I disagree, as any complex project is going to need a lot of time and effort. The main difference is where that time and effort is spent.
Using a Black Box gives an initial head start. You could develop an MVP very quickly; but you may be slowed down in the future when you need to add functionality, but can’t quite understand the programming conventions used. Creating your own “transparent box” may be slow to start with, and you may be creating things which already exist; but you will save the time and effort in the future when adding new functionality.
If you are building something simple, which will have no need for any additional functionality in the future, such as a blog, then use a black box platform. That is what they are for. If you want complex functionality, or the ability to make the system do exactly what you want in the future, plus understand how it works, then maybe a bespoke system would be better. There is nothing worse than trying to force something to do or be something it’s not meant to do or be. What initially seems like a time saver may end up taking more time, and lead to a system with problems.
