6 ms·

Lessons Learned from Shutting Down My Second Startup

42 points by venturefizz 16y ago

dasil003 16y ago
Mirrors a bit of my own experience doing agency work. We actually built a site for a client Drupal, and then completely scrapped it and rebuilt in Rails because some seemingly minor interface improvements would have been impossible to complete due to the structure and interaction of a couple modules. CMS solutions are good for only one thing: giving people a bunch of boilerplate functionality when that's all they can afford. Building a product on top of a CMS is a sure route to a mediocre product surrounded by dead-ends.
- mikeocool 16y ago
  Agree, so very strongly. Got about 4 weeks into a client project with Drupal and scrapped it in favor of Django. I've been continually mystified every time I see folks singing its praises, but you bring up a fair point, it provides a lot of out of the box functionality. Extending or changing that functionality just turns out to be a nightmare.
  - spyrosk 16y ago
    What about hybrids like Silverstripe? Has anyone used it (or something similar) for large-ish projects? Although personally I use mostly CakePHP, I began playing with it lately and it seems to me that it has a lot of potential. Basic CMS functionality is provided out of the box, but I really like the way you can extend the core classes and integrate your own functionality into it, without losing the typical ease of use, even for non developer maintainers/users.
    - mashmac2 16y ago
      What differentiates Silverstripe from something like Django? It seems to me like Django offers 'Basic' CMS functionality, althought how you define that is up to you :)
      - metachris 16y ago
        I personally prefer frameworks that get out of my way over Django which forces a lot of idioms onto you. Like web.py, and if it's your taste add Jinja and SQLAlchemy and you've got a decent stack to quickly iterate.
  - knieveltech 16y ago
    Drupal has a learning curve like the Matterhorn, plain and simple. Based on observations made over the last four years I'd say the majority of projects started using Drupal with competent developers who have little or no prior experience with the CMS typically fail. The odds improve drastically as a team's familiarity with Drupal grows.
    - ams6110 16y ago
      Drupal is a CMS, not a general purpose web app platform. There are a few Drupal modules that are essential do doing anything remotely "custom" and the most important of these I would consider to be CCK, Views and Panels. Many of the better modules integrate with Views. The top 20% of Drupal modules are decent, the remainder are to varying degrees quite amateurish. If you find yourself writing a lot of PHP on a Drupal project, you're doing it wrong. It's not just that the learning curve is steep, it's that the internals are a steaming pile. The code is straight out of the last decade: large PHP functions sprinkled with SQL queries built up from concatenated strings. It's no surprise that SQL injection vulnerabilities are still being found on almost a weekly basis in one module or another. There is absolutely no transaction management; the assumption is that a Drupal site will be modified by a few and viewed by many. The functionality of Drupal is powerful. But stick to using modules and maybe a little bit of PHP helper code. If you are implementing a lot of custom logic in PHP, you're better off using a more conventional (modern) web app framework.
      - knieveltech 16y ago
        I think we're on the same page more or less but there are a few points I'd like to clarify: 1. I'm aware that Drupal is a CMS. 2. I don't find myself writing a lot of custom code on my Drupal projects and that's the entire point (for me anyway) of using it as a dev framework. 3. You have a few thousand developers of various skill levels submitting modules and the quality is absolutely going to vary from module to module, this is unavoidable. Learning to vet your modules carefully and taking a less is more approach with module installation is part of the learning curve. 4. Drupal's internals are a steaming pile compared to what, exactly? Ever taken a look at Wordpress's core code? All code sucks.
- knieveltech 16y ago
  Couldn't disagree more, and that's after having lived through just the situation you and the OP both described. Pick the right CMS for the job, make sure your people are fluent with it (this is key) and you vastly reduce the amount of wheel reinvention not to mention effectively outsourcing large swaths of your codebase to a community of a few thousand developers. 100% bespoke makes sense if what you're doing is trivially easy or a complete departure from the available canned feature set of a CMS, in all other instances you're artificially limiting your pool of developer talent and taking on massive technical debt in the form of code you're on the hook to maintain.
  - dasil003 16y ago
    I get what you're saying, but this is what I characterized as boilerplate. It's not a totally fair characterization, since Drupal gives you a lot of freedom. It's not particularly limiting in the design sense, modules are highly configurable, and the provided hooks let you do pretty impressive things with existing code. Drupal is an amazing piece of software for what it is. However the out of the box functionality comes with a lot of baggage. You never use all the functionality, yet you are forced to deal with the implications of that functionality. The design decisions are meant to support arbitrary content, but for most sites you have very specific content. If what you are doing is boilerplate functionality, then a CMS saves you a lot of time. However as things diverge from the standard case, the weight of the infrastructure can become crippling very quickly. An example was that I needed to reverse the order of two of the checkout screens in the Drupal ecommerce module. For the project in question this was a dramatic improvement to the user experience. There were no hooks to accomplish this, instead it had to be hacked into the ecommerce module. But the ecommerce module is incredibly complex. It attempts to do anything you could possibly imagine, 95% of which was not needed for this project, yet in order to hack in the solution, it was necessary to understand those issues holistically. The time to figure that out, hack the module and test it was longer than just grabbing ActiveMerchant and coding up a checkout flow in Rails from scratch. If you just let Drupal modules do what they are designed to do, then yeah it's amazing, but a great user experience is highly tailored to the application at hand. My experience is that even when you are doing something that a CMS is well-suited to, you still end up making little concessions to the architecture you are dealing with. Those concessions might be worth the cost savings, but it's undeniably a tradeoff. For me personally after a while I felt crippled by it—I couldn't stand my UX to be influenced by software designed for mass solutions. I believe the sweet spot is in frameworks and libraries with fine-grained tools so you can use only what you need without accepting any baggage you don't.
metachris 16y ago
One of the gems in this post: "Self-motivation is not an ability that once you have it, you keep it. It’s a reservoir of will that’s filled with ambition, enjoyment, good humor, and small successes. It’s drained by mundanity, difficulty, failures, and fears. If you’re not refilling that reservoir on a regular basis, you will find yourself attempting to escape or avoid further drain."

42 points by venturefizz 16y ago

Mirrors a bit of my own experience doing agency work. We actually built a site for a client Drupal, and then completely scrapped it and rebuilt in Rails because some seemingly minor interface improvements would have been impossible to complete due to the structure and interaction of a couple modules. CMS solutions are good for only one thing: giving people a bunch of boilerplate functionality when that's all they can afford. Building a product on top of a CMS is a sure route to a mediocre product surrounded by dead-ends.

mikeocool 16y ago
Agree, so very strongly. Got about 4 weeks into a client project with Drupal and scrapped it in favor of Django. I've been continually mystified every time I see folks singing its praises, but you bring up a fair point, it provides a lot of out of the box functionality. Extending or changing that functionality just turns out to be a nightmare.
- spyrosk 16y ago
  What about hybrids like Silverstripe? Has anyone used it (or something similar) for large-ish projects? Although personally I use mostly CakePHP, I began playing with it lately and it seems to me that it has a lot of potential. Basic CMS functionality is provided out of the box, but I really like the way you can extend the core classes and integrate your own functionality into it, without losing the typical ease of use, even for non developer maintainers/users.
  - mashmac2 16y ago
    What differentiates Silverstripe from something like Django? It seems to me like Django offers 'Basic' CMS functionality, althought how you define that is up to you :)
    - metachris 16y ago
      I personally prefer frameworks that get out of my way over Django which forces a lot of idioms onto you. Like web.py, and if it's your taste add Jinja and SQLAlchemy and you've got a decent stack to quickly iterate.
- knieveltech 16y ago
  Drupal has a learning curve like the Matterhorn, plain and simple. Based on observations made over the last four years I'd say the majority of projects started using Drupal with competent developers who have little or no prior experience with the CMS typically fail. The odds improve drastically as a team's familiarity with Drupal grows.
  - ams6110 16y ago
    Drupal is a CMS, not a general purpose web app platform. There are a few Drupal modules that are essential do doing anything remotely "custom" and the most important of these I would consider to be CCK, Views and Panels. Many of the better modules integrate with Views. The top 20% of Drupal modules are decent, the remainder are to varying degrees quite amateurish. If you find yourself writing a lot of PHP on a Drupal project, you're doing it wrong. It's not just that the learning curve is steep, it's that the internals are a steaming pile. The code is straight out of the last decade: large PHP functions sprinkled with SQL queries built up from concatenated strings. It's no surprise that SQL injection vulnerabilities are still being found on almost a weekly basis in one module or another. There is absolutely no transaction management; the assumption is that a Drupal site will be modified by a few and viewed by many. The functionality of Drupal is powerful. But stick to using modules and maybe a little bit of PHP helper code. If you are implementing a lot of custom logic in PHP, you're better off using a more conventional (modern) web app framework.
    - knieveltech 16y ago
      I think we're on the same page more or less but there are a few points I'd like to clarify: 1. I'm aware that Drupal is a CMS. 2. I don't find myself writing a lot of custom code on my Drupal projects and that's the entire point (for me anyway) of using it as a dev framework. 3. You have a few thousand developers of various skill levels submitting modules and the quality is absolutely going to vary from module to module, this is unavoidable. Learning to vet your modules carefully and taking a less is more approach with module installation is part of the learning curve. 4. Drupal's internals are a steaming pile compared to what, exactly? Ever taken a look at Wordpress's core code? All code sucks.
knieveltech 16y ago
Couldn't disagree more, and that's after having lived through just the situation you and the OP both described. Pick the right CMS for the job, make sure your people are fluent with it (this is key) and you vastly reduce the amount of wheel reinvention not to mention effectively outsourcing large swaths of your codebase to a community of a few thousand developers. 100% bespoke makes sense if what you're doing is trivially easy or a complete departure from the available canned feature set of a CMS, in all other instances you're artificially limiting your pool of developer talent and taking on massive technical debt in the form of code you're on the hook to maintain.
- dasil003 16y ago
  I get what you're saying, but this is what I characterized as boilerplate. It's not a totally fair characterization, since Drupal gives you a lot of freedom. It's not particularly limiting in the design sense, modules are highly configurable, and the provided hooks let you do pretty impressive things with existing code. Drupal is an amazing piece of software for what it is. However the out of the box functionality comes with a lot of baggage. You never use all the functionality, yet you are forced to deal with the implications of that functionality. The design decisions are meant to support arbitrary content, but for most sites you have very specific content. If what you are doing is boilerplate functionality, then a CMS saves you a lot of time. However as things diverge from the standard case, the weight of the infrastructure can become crippling very quickly. An example was that I needed to reverse the order of two of the checkout screens in the Drupal ecommerce module. For the project in question this was a dramatic improvement to the user experience. There were no hooks to accomplish this, instead it had to be hacked into the ecommerce module. But the ecommerce module is incredibly complex. It attempts to do anything you could possibly imagine, 95% of which was not needed for this project, yet in order to hack in the solution, it was necessary to understand those issues holistically. The time to figure that out, hack the module and test it was longer than just grabbing ActiveMerchant and coding up a checkout flow in Rails from scratch. If you just let Drupal modules do what they are designed to do, then yeah it's amazing, but a great user experience is highly tailored to the application at hand. My experience is that even when you are doing something that a CMS is well-suited to, you still end up making little concessions to the architecture you are dealing with. Those concessions might be worth the cost savings, but it's undeniably a tradeoff. For me personally after a while I felt crippled by it—I couldn't stand my UX to be influenced by software designed for mass solutions. I believe the sweet spot is in frameworks and libraries with fine-grained tools so you can use only what you need without accepting any baggage you don't.

metachris 16y ago

One of the gems in this post: "Self-motivation is not an ability that once you have it, you keep it. It’s a reservoir of will that’s filled with ambition, enjoyment, good humor, and small successes. It’s drained by mundanity, difficulty, failures, and fears. If you’re not refilling that reservoir on a regular basis, you will find yourself attempting to escape or avoid further drain."