Immature developer attitudes revealed in flames regarding CDBaby

Derek Sivers of CDBaby kicks ass. He got a sophisticated and very very user-friendly, efficient, straightforward e-commerce system (including the back-end systems) written in PHP. Based on what I’ve read, he’s up there with Phil Greenspun in my opinion; that is, he’s among those who understand strategy and customer service and low-level technology and are able to build systems that don’t suck, resisting the temptation to be distracted by technological panaceas and fads. I may disagree with their individual technology decisions, but their higher-level thinking is excellent, so they’re definitely in the class of people who I’ll give the benefit of the doubt.

So when I read 7 reasons I switched back to PHP after 2 years on Rails I was a bit surprised, but not much. He’s experienced with PHP (he says he’s written 90,000 lines of code for CDBaby!), and has a huge installed base of code he wrote and understands intimately. He tried Rails, it didn’t work the way he wanted, and he went back to PHP. It was immediately obvious to him that this was what he should continue using.

The most shrill and arrogant among the Rails community have been rather unkind, partly due to this rather poorly written Slashdot headline that misrepresents what Derek says in his article.

I’m using Rails and I’m generally happy with it, though I have had to do some customization of the framework (mostly with pre-existing Rails plugins from like-minded developers) to suit my style. At this time I plan to continue using Rails for my project, and to keep using it in future projects.

But, I thought it would be instructive to summarize the arguments made by the folks slamming Derek in the comments to his article.

  • Rails is the correct solution for CDBaby, regardless of what the founder//designer/lead programmer of CDBaby thinks.
  • If you don’t agree with Rails’ design, you’re wrong, and you need to change your design if not your whole business to fit Rails.
  • PHP is bad and can never result in good code. Conversely, Ruby is good and is always better than PHP.
  • Objects are better than SQL and tables. Domain specific languages are great, as long as they’re written in Ruby; using SQL as a domain specific language for data manipulation and querying is not Ruby and therefore is a bad idea. Also, just because one person can code something in PHP in 2 months that runs on one server, instead of two people taking over two years to do it in Rails (which is notoriously hardware-hungry), doesn’t make PHP + SQL better. Because objects make you more productive.
  • Just because you wrote a successful online store yourself from scratch, have an O’Reilly column, and then hired a Rails core team member who now works for the same company as most of the rest of the Rails core team including DHH (37Signals), doesn’t mean that you actually had people smart enough to rewrite your app in Rails. You need to prove to the world that what you wanted to do was impossible in Rails before we’ll give you permission to make technical decisions for yourself.
  • If you don’t like Rails it must be because Rails is too good for you. Maybe instead of learning from years of real world experience running a business and writing the entire software suite for that business yourself, and hiring one of the best Rails developers in the world for your transition to a new architecture, you should have gone back and gotten a CS degree.

Since this is such an active flamewar with such sloppy readers (responding to the Slashdot headline’s misapprehension of what Derek wrote, instead of what he actually wrote), let me say this clearly:

The above listed points are not my opinions. They are summaries of opinions I find immature and silly.

(I’m assuming someone somewhere will read this post in anger and make themselves look foolish by arguing against these points as if I believed them anyway. I tried to warn ya…)

We can learn something from this. This same flamewar keeps appearing over and over and over, all over the internet, and before that, on BBSs and in print.

The simple fact of human mortality means that most of us are going to be learning and making mistakes that we imagine a wise, seasoned developer wouldn’t make. But that guy retired and is fishing, so it’s up to us to screw up and learn and hopefully do better next time.

For the last few thousand years, we’ve had the advantage of being able to read books, and get wisdom that way. But there are fads, and hyped books that seem to know it all. So you have to read a lot of books, and try a lot of contradictory ways of doing things, to get a mature enough perspective to make wise choices on future projects.

The point that is generally missed by everyone trying to do anything new to them, is that there’s a lot more out there that you don’t understand, and a lot of what you think is your brilliant new invention has been done before. The more you learn, the more humble you become as you learn that there are people WAY smarter that you are, and that there are people who have come before you who you will never catch up to.

In the case of web development, that means that there are people out there who disagree with you, and you might not actually know everything about everything like you think you do. Local experience and immersion in the problem they’re trying to solve makes them much better suited to solving their problem than some armchair quarterback. It’s tempting to fold your arms and feel smug about your quick dismissal of someone else who clearly isn’t as big a genius as you are, but the more certain you are of your own brilliance, the more likely it is that you’re just ignorant. (See also: Unskilled And Unaware Of It.)

In Derek’s case, he clearly jumped feet first into Rails and hired a rockstar developer, and then made the decision given a uniquely advantageous perspective that it just wasn’t working, after giving it a hell of a lot more time to pay off than I would have. (I’m not exactly sitting here scratching my head wondering “how could Derek have been so wrong?”)

What matters a lot more than choice of programming language is the ability to get the project done, meaning tested and correct and launched. Apparently for Derek, PHP is the way to get that done, and Rails ain’t.

Finally, consider the parallels between Derek in this case, and Phil Greenspun in his book (late 90’s). They both use SQL more than the “Objectistas” would like, which is to say, they use it directly and like it. They both use languages that are not the most fancy high level languages available, but they do completely understand how their application works, from UI all the way down to hardware performance, and they make integrated decisions that take business strategy and technological factors into consideration.

This is really critical to understand about why both of these guys are so smart: both of these people put aside dogma and made decisions that were all over the map, sometimes pragmatic and hackish, sometimes very rigorous and disciplined, depending on their assessment of the particular micro-issue they were addressing at the moment. They weren’t subscribing to any particular software development philosophy (Big Ball of Mud, XP, RUP, UML, Agile whatever, waterfall, etc.), nor did they just choose the most hyped architecture of the day and blindly stick with it, but freely mixed and matched whatever they thought was appropriate given their perspective on the situation.

In other words, they didn’t fall into the trap of thinking that there is One True Way to do everything. They improvised. They integrated their own experience and perspective with the wisdom of others, and made the decision that worked for them.

I hate to sound like a moral relativist, because I’m not. But as a practitioner, I’m definitely becoming more and more of a process relativist every day. One of the best ways to make a project fail is to try and force-fit an architecture and/or a methodology onto that project without customizing them to the particular details of the project. The best methodology is called “Roll Your Own.”

And so I leave you with this question, in the hope that it will help you with your current and future projects: Have you made any dogmatic decisions about your process or technology that are hurting your project?

Maybe it’s smarter at this point to keep doing what you’re already doing, but maybe there are some things that you could change. Try to keep your Mind Like Water, strong enough to cut through mountains but flexible enough to flow around obstacles, and making the decisions of which one to do based on the information that you and only you have.

29 thoughts on “Immature developer attitudes revealed in flames regarding CDBaby”

  1. I think he should have made it more strict.

    Rails vs PHP

    But he compares

    Ruby/Rails vs PHP

    I think this is problematic. Just because Ruby allows to do
    a great many things, doesnt mean you *have* to use them.
    And if the codebase of rails is too complex, but you feel
    as if rails is putting a block into your way… dont use
    Rails … ;)

    But why not use ruby? He has given no answer to that, in fact
    he made it look as if PHP can do something ruby
    can’t – but without explicitely naming it.

    Instead he claimed that when you are a better programmer, you
    can produce better code. I am using PHP since +5 years
    by now, ruby since ~4 and I can NEVER agree on this.
    The PHP code _looks_ worse, no matter how hard I
    try to use as many clean and good concepts as possible.
    To me it is as if you are comparing a knife to a
    katana… you can slice with the knife but it doesnt
    inflict big wounds and once you must cut trees, the
    knife is worse than the beautiful katana (i
    mean small and young trees, not big trees…
    big trees are best cut with the java mech, but
    the java mech is so slow and heavy that he will
    instead just roll over the trees instead of
    cutting them… and the steam coming out
    will make people dizzy so its dangerous
    to be near it …)

    Back to the web:
    This is EXACTLY where ruby should jump in. There are not
    many features I believe would be needed to make ruby
    competitive with php in such a way that people would
    pick it the way those “script kiddies” used to pick
    php – because it was for the web! (the clean syntax is
    on ruby’s side … just dont throw lambdas at the
    youngsters, they arent needed to get a job done)

    So maybe whats needed?
    – good apache integration (mod_ruby isnt perfect)
    – same layouting way as PHP allows out of the box (after someone
    compiles ruby… installing addons will never work)
    – clear ways for database connections

    And maybe some more minor points, but I believe these things
    CAN be solved if people would agree that ruby would need them
    (or be advantage)

    I am reading stuff like “Erlang is the future” but for now,
    the future is still the world wide web, and i dont think
    this is going to change in the next few years at any time,
    no matter how many more erlang hypes, dual-core multi-core
    threads hypes or whatever come up.

    Its the web!

    PS: Whops sorry, my comment became way too long… :(

  2. As soon as I saw the CDBaby original post on reddit, I realized there’d be an enormous rant-back brewing among the fanboys. I didn’t even bother to go back to read the comments, but I knew they’d be somewhere along the lines of your summary. It’s good to see that there are sane voices who believe in using the right tool for the job.

  3. Frankly I’m sick of these kind of flamewars, the mixture of hubris and ignorance is nauseating. Generally there are a few nuggets of wisdom floating in a vast sea of extremely ignorant comments fueling the fire from both sides; this baits more reasonable people to write intelligent rebuttals–but what is really gained?

    Even the smartest developer in the world can’t know everything. There’s a lot to be gained from getting other developers’ perspectives, but a flamewar is the absolute worst context. It’s better to simply work on a variety of teams and engage in different communities. If you think you’re smart and care about your craft, then it should be clear that flame wars are a complete waste of your time that could be better spent learning something new.

  4. There’s a Latin dictum that summarizes this issue: “Timeo hominem unius libri”. In english: “I fear the one-book man”. People who decide to stem all their thinking from a single model can’t accept (tolerate) difference. This is true in general and particularly as concerns languages, programming or not. Languages vehiculate our conception of the world, so discussion about them are much akin to discussions about religion or politics.

  5. Damn, Jamie!

    Great article.

    Thanks for capturing the essence of the comments, giving me the best laugh of the morning, then having an incredibly wise perspective on it all.

  6. Thanks for providing a balanced look at Derek Sivers posting. I was also shocked to see such anger and spite from some of the RoR community. Whether you agree or not, Derek’s post was intelligent, well-written, and (I thought) very informative.

    Not every dev environment can use a cookie-cutter solution. The past and present are a big factor in deciding the steps for the future. I think Derek shared his experience in a very straightforward, honest way. If you don’t agree, move on and read something else.

  7. Very well put. I think the secret here is two-fold, particularly when working with others:
    1) Use what you are comfortable and productive with
    2) If there is more than opinion on what technology you should use, “BE FLEXIBLE” and open minded. You might learn something in the process.

    I like what you say: “Try to keep your Mind Like Water, strong enough to cut through mountains but flexible enough to flow around obstacles”

    I’m a huge PHP fan, (so from alot of people’s opinion, I lose points right there) but its what I’m good at, what I am efficient in, etc. I’ve “played” with RoR and I like that too, but I’m just not at that comfort level yet (I’ve written a few apps that I just haven’t “finished”). I’m currently working a bit with Django as well and actually like that more than RoR. And Java, well, that bitch pays the bills :)

  8. I agree, definitely. Especially about the immature developer part. All those people that get so bent out of shape when someone decides Rails isn’t for them really don’t show so well on our community. As programmers and developers, we should embrace all tools of the trade. Even if you think that Rails works in every situation, it would behoove you to at least not be hostile towards other tools. If you block out all the ‘competitors’, what’s driving you to improve? Part of what makes open source software and software in general so awesome is the mishmash of ideas that occurs.

  9. I like your post and share your concern with the tone of some in the rails community. I also enjoyed mind like water analogy. I hadn’t heard that before.
    Here is my take on part of the issue with the aggressive, vocal portion of the rails community. If you have the opportunity, I’d appreciate hearing thoughts:
    Rails is Not Opinionated

  10. Hi Jamie,

    I’m glad to see your thoughtful summarization and open minded reading of Derek’s experience. While reading Derek’s post I kept wondering how you would interpret it, only to find half-way through the comments a link to this post.

    For my part, 4 years ago I tried to jump from custom Cold Fusion 5 work into Java with Struts and Hibernate which resulted in a period of years of inefficiency where I kept asking, “Where’s the payoff? Has this been worth it?”

    Call me slow witted, but it has only been in the last 9 months or so that I have started to feel benefits from moving away from Cold Fusion, and like Derek suggests the benefits are not the new language but rather new skills drawn from being challenged to see old problems in new ways. I’ve gained the most by focusing my attention away from frameworks and towards using the language itself to solve my business problems: code that synchronizes data from independent databases; analyzes data and writes report; etc. By learning to really grok layered diagrams, and then to specify what part of my problem space is back-end, and what is front end, where are the boundaries and what is my API, I’ve been able to see how a number of front-end frameworks could be integrated. For my part, now that Struts 1.x is going dormant, this process has helped me feel more confident in evaluating front-end frameworks based on how they interpret the job of a front-end API.

    There is no doubt that front-end work is important, but where I’ve learned the most has been when I get to use a programming language to solve a problem that results in a simple programmer’s API. Not only do get to test the language without distraction, but when it comes time to plug into a UI there’s a nice clean hook to do it.

  11. ah so true, toady it seems a war very much alike the political campaigns is taking place. Whatever publicity the other camp get, throw dirt and shit and call them idiots. Just to scare of possible new programmers and the existing ones.

    I say go with a language you like and feel comfortable with, don’t listen to what groups have to say, especially the ones that behave in these childish manners.

  12. That blog post was overall a pretty poor one. I was surprised to read something like that on an O’Reilly blog. The reason why his project failed is most likely very poor project management (TWO YEARS of development?? He must be kidding). He also doesn’t differentiate between “Rails” (which is a framework), “Ruby” and “PHP” (which are programming languages). Last not least he doesn’t even try to go into detail, ie what exactly didn’t work for him in Rails (“I spent two years trying to make Rails do something it wasn’t meant to do” – what is this “something” he’s talking about?), which almost makes that post a rant itself.

    I am sure that that blog post would have received way less flame comments if it was written better. Although it probably wouldn’t have been slashdotted then.

  13. Derek Sivers is truly an awesome guy. I’ve worked with CD Baby before (just as a musican putting out an album) and it was an excellent experience. Just today I got an email directly from Derek asking for really general feedback on what I think would be the most important thing that could help my music career and how he could help with that. It was just a mass email, but it was very sincere and I believe he is really out to help people.

  14. What I found amazing was all these so called smart guys that looked at the cdbaby site and balked at the 100k lines of code that was taken to write it as if you can some how judge the functionality of a system just by its public interface alone

  15. @Claus Wahlers

    First, remember, that “very poor project management” involves a core developer of Rails itself.

    Secondly, I’m sure everyone here is fully aware that Rails is *yet another magic-bullet framework* and PHP is a language. However, in this case, it doesn’t matter that he compares the two. His two choices in this case were Rails on Ruby (Ruby on Rails is so backwards) and PHP. He went with PHP. You might proclaim loudly that they are completely different and cannot be compared, and yet, he just did.

    Thirdly, while I lament that he didn’t get into more detail about what he was trying to do, would it make a difference if he spelled it out for you? Here is what you need to know. A core Rails developer (someone I’m going to trust more than most others with knowing how Rails works) was working on the project. CDBaby is a website. It works a certain way, and at the time, it was, in fact, working just fine. It was ugly, but it was working (and I’d take working over clean design any day of the week). Also, he made it clear that his intent was to simply do the switch, and he didn’t want to do incremental changes. This partly hindered the process (and, I imagine, a limitation of Rails).

    Finally, no, the blog post would not have received less flame comment if it was written better. Time and time again, I’ve seen people post why they move from Rails to PHP, or talk about their Rails problems, and the armchair developers come out of the woodworks with seemingly simple solutions (just add more hardware, that’s a database problem, or Rails is just a framework) that aren’t really simple and don’t really solve the problem.

    Rails is opinionated by design. While some people might share this opinion, it’s not the only opinion on the block, and a lot of smart people don’t agree with that opinion, and when they disagree, the Rails horde jumps in and lashes out with, well, useless arguments. Rail’s can’t solve all the problems! Rails can’t solve most of the problems. It can solve the problems it was designed for: websites for people that think a certain way and only a certain way.

  16. The opinnions are immature and silly because they are made from a very naive approach to software engineering. Plus, the Talibans’ style arguments from the RoR community do not help at all…
    The methodologies and technologies must be adapted to our needs: it does not work the other way around.

  17. Dear Jamie,

    Thanks a lot for your comment. I couldn’t have done it better!

    Regards
    Olivier

  18. I just want to state full agreement with Jason above. Of course you can compare Rails to PHP!

    The argument that you can’t compare them comes from the discussion of which is better _in general_. But we’re talking about tools for a specific case here. And PHP and Rails are both tools.

    This is like the saying “You can’t compare apples to oranges,” which is clearly wrong. For example: “Which one has a more bumpy surface?” Sometimes it’s amazing that some people can forget that the truth of an answer depends on the question.

    -phaylon
    (neither Ruby nor PHP dev)

  19. Religious flame-wars like the Rails vs PHP one are an old staple of the Internet, going back to Usenet and mailing lists. I never did understand it.

    I mostly use Ruby on Rails to develop my employers web applications, not because “I got religion”, but because I’ve found myself most productive using that framework. Is that going to be true for everyone? Obviously not. It’s true for me, and that’s enough. I don’t lay away at night, tossing and turning because someone else finds themselves more productive in PHP or Python or whatever. Meh.

    I’m a pragmatist, and I’ve wound up in my career doing work using PHP, J2EE and .NET. I’m a developer, not a Rails developer, and I’ll use the tool that best suits the needs of the moment. Today, Rails is my preferred tool for most cases. Yesterday, it was J2EE. Tomorrow, it could be something else.

    It’s also worth noting that the raging dog-pile that the comments to the original blog post is actively harmful. For example, a poster named Bob made a comment about ActiveRecord that showed his lack of understanding. He’d probably benefit from looking into :include, :join and :conditions, but the childish battle raging in that thread makes discussing things like this impossible.

    And so the war continues …

  20. What slays me about that whole comments thread are all the armchair devs and trainspotters who took one look at CDBaby, decided it was simply an online CD store and decided they could write it in X in a few months. (Or the guy who suggested, at length, PostNuke!) Well, yeah, if you were writing from scratch with no regard to the existing customer/distributor/client structure, functionality and core. CDBaby is an online distributor for independent musicians and labels. It is not a simple web application, and would need to have what must be a large database migrated or adapted. It’s not Joe’s Fly Fishing Web Shop. And anyone who has worked on large-scale enterprise site knows that a 2-year turn-around is not only reasonable but likely to be derailed (hee hee) by all kinds of complications.

  21. When you write an alarmist title you get what you deserve. His points were quite moot and his knowledge of the framework he was bashing was poor. My comments were civil, but I did point out the ineptitudes of his article.

    However when every day I see such alarmist muck being put out for the world to see, Ii can understand why the rails community respond in the way they do.

    Rails is not PHP or Java, it is newer and therefore more vulnerable to losing marketshare over spewed garbage, so we react. While a large group of the rails community seems to be quite young and therefore do not have the social skills to sound like anything but WOW players, there are quite a few of us with tact as well.

    It is just more fun to read the l2p (learn to program) comments :)

Leave a Reply

Your email address will not be published. Required fields are marked *