On the Dutch Web Alliance blog today Stefan Koopmanschap talks about making technology choices, how flexibility comes into play and suggestions on what to do when things go wrong. He uses some of his own experience (and problems) to illustrate his points.

The amount of times I come into an organization that says any of the above is impossible to keep track of on one hand. Or even two. Most development shops for some reason have decided that they have a single tool that will fit the job. Always. I have to admit the current market is good for developers. There are many projects available, and not enough developers or agencies to work on all of them. [...] But too many times have I encountered projects where the used tool actually was not optimal for the project. I would like to make a case against starting with a full stack from the start. Obviously, this approach does not work for all projects, but too many projects start out small but with a full stack. I’m going to take an old project of mine as an example of how to start out small and not grow until you need to.

He talks about the project first, a transcoding tool that used a third-party service and generate a playlist once the process was complete. He shares some of his thinking about the technology involved (Symfony2 without the full Symfony2 stack) and the decision to go with Cilex. He also talks about database choices (PDO over Doctrine) and how starting with small pieces like this makes it easier to change things in the future (or when a roadblock looms ahead). Then comes the "what went wrong" part of the development - debugging the system without the direct access needed to view the logs. Instead he worked around it, made a simple endpoint to show the logs and output it via Twig templates.

The result of all this work, including changes and extensions, was still a very small and lean application that combined the power of the commandline with a simple but effective web interface. I am sure I could have done a similar thing with Symfony2, but the code would’ve been overkill. [...] It is important to realize that there is not always a need for full stack frameworks or huge CMS’es like Drupal. Sometimes you need to start small and just let it grow.