Common issues with web projects
Here is a list of very common issues I came across in the development of web projects, and how to (hopefully) avoid them. As you will see, many of them are not really related to technology.
Needs not needed
This is probably the most common one: many clients come up with a long list of needs, which would require a huge system. If they have enough money to build this system and you actually end up building it, you will most probably be frustrated by the fact that they end up really using only 10 to 20 % of the features you built… There are various causes to this: some clients would like to have a system that will handle every single possible case that could ever possibly happen, and could make you spend a huge amount of time on an edge case that will never happen; others just have no idea how much time, effort and money is required to build feature X, and they just throw a list of features at you “just in case” they might be needed in the future.
Here is how you could react to such a behavior:
- If your client has enough money to build this giant system, and you don’t mind wasting your client’s money, then you could just build it ! If you’re like me, you’ll still end up frustrated from the fact that what you’re building is actually not being used, no matter how high the paycheck is.
- You could try to convince your client that he will be better off not building this feature, because he doesn’t really need it. Depending on the person you have in front of you, it might be hard, but it can work.
The solution that I tend to prefer however is to go through an iterative process to build the system, starting with a Minimum Viable Product, and adding the rest of the functionalities as there is a real need for it, through an Agile process. This usually allows the client to find out by himself that he doesn’t need all the bells & whistles he had dreamt of.
Reinventing the wheel
If you work for big companies or big international organizations, you will most probably have to deal with many of their sections. Given that each section works independently from each other, you might find out at some point that the work you’re doing has actually already been done more or less for another section of the company, and that you’re just redoing (maybe with a fancier, newer programming language and platform) what has already been done 2 years ago for another section.
If you really want to help your client out and reduce his costs, you might stand up and say: why don’t we integrate the work that I’m doing with the already existing project ? Or, since your work is obviously much better than the way the older project was done, what about integrating the older project within your work ? So you try to have the 2 sections talk to each other, and starts a long political discussions, with everyone being in favor of the integration, but no one really willing to actually DO IT. Way before this political discussion is over, you are done with your project and you move on, with the hope that integration will happen at a later point.
I still didn’t find a real solution to this one. One potential solution is to try to build software as services instead of closed blackboxes, so that if another section needs the same kind of service, they should at least more easily be able to reuse the service you built. That said, even if you build things as services, if there is no political push in the organization to make sections reuse the work of other sections and talk to each other, you will still be reinventing the wheel for a while.
This issue is one that is not related to the clients, but to the love that some tech firms and individuals have. If you’re building a simple Drupal site with a few static pages, a blog and, say, a few events, do you really need to use Grunt ? Do you really need SASS + Compass ? Do you need a fully virtualized environment with Docker or Vagrant ? How many dev ops do each of these elements add, and for which real benefit ?
I’m not saying you should never use the technologies mentioned above, even when doing simple projects, but when doing so, keep the following in mind:
- How much time are you spending on dev ops vs on the actual project ? If you spend more time on dev ops than on the project, you should probably give it a second thought.
- If some day you leave the project, how hard will it be for someone else to get up to speed ? How many things will the newcomer have to learn ? How many steps will be required to install the dev environment ?
For simple Drupal projects, I try to keep it as simple as possible: one single CSS file for the whole theme, based on Bootstrap and Fontawesome, and as less modules as possible to keep things simple: no Grunt, no SASS, no Compass… Docker or Vagrant can still be used if wanted, but the site can still be run without it.
There are, of course, many more issues that can be encountered when building web projects, but those are, for me, the 3 top ones. To try to avoid them, keep it simple and try to understand as much as possible your client’s real needs.
Originally published at https://www.gvj-web.com on December 2, 2015.