jetheredge

As the owner of a digital product agency, this is really hard to read. It is such a shame that an agency would do this to you. I know you felt like they "did their best", but by setting you up with unrealistic expectations out of the gate they essentially guaranteed that everyone was going to walk away unhappy. Besides, when you go to an agency communication/transparency/team of experts is what you are paying for! You're paying for accountability! There really are good agencies out there that care about their customers and bend over backwards to deliver what they promise, but they are hard to find. For the size project you were looking at though, I do agree that a freelancer could have been a better option, but you'll run into some of the same challenges. Finding good freelancers can be just as hard as finding a good agency.

We build and maintain a lot of Rails applications, with several of them almost a decade old. We have to keep them up to date, but Rails is stable and mature and this process is fairly easy. We come across a lot of web apps written in other ecosystems, using frameworks that were popular just a few years ago and have now been mostly abandoned. Or we get bit by an app that is a few years old and now has dependencies that are completely dead and core to the application. This isn’t the case with Rails. It is just as actively developed now as it was 10 years ago, and we are confident that it’ll be just as actively developed 10 years from now. Due to the fragmentation of these other ecosystems, even though the community as a whole may be larger, finding a stack that you can depend on for a long time can be a huge challenge.

This post isn’t about a single snapshot in time, this is about all of the people who didn’t evaluate MongoDB properly over the years and then were “burned” by it. I actually think it has received a bad rap due to people over the years not evaluating it properly. Sure, some of these things have changed (transactions very recently), but they all come with serious caveats and limitations that need to be explored... which was the main point of the article.

Author here... we talk a lot at our company about essential complexity and incidental/accidental complexity. Software is complex, absolutely. It is complex because business and reality are complex. I think that is inescapable. What we can try to escape though is the incidental complexity that we add to our systems while we are following trends or chasing down shiny new tools.

Author here... I agree that developers often lose sight of the business problem being solved, but I think just stopping there is an over-simplification. It is very possible to build an application that serves the business problem adequately, but is grotesquely over-engineered or solves the problem in a ridiculous way. The world is built on software like that. My point was that we are introducing a lot of needless complexity to systems, all in the name of following trends or chasing the new shiny. And we are hurting ourselves by doing it.

Author here... yeah, we are loading a lot of crap, aren't we? We will do an audit and make sure we aren't loading a bunch of unnecessary stuff, but the whole site should be served up through a CDN, sorry it is loading slow for you.

I've felt like any project horribly out of date is a pain to get current, Rails is no exception to that. Sure, many Rails projects have a lot of dependencies, but so do other frameworks. Sure, part of your argument is static vs dynamic, but I'm not going to join you in that argument.<grin>

I considered speaking to that, but then I felt like I was delving into religious arguments. My framework is more efficient than your framework! I felt it would have drawn people away from my main point, which is to think deeply about the tools you choose, and everyone needs different tools.

This is ridiculous. Google is purposely designing their sites to use more Ajax so they can take down Firefox? This has to be a troll.

Not a PHP programmer, but a fellow Richmonder. Howdy.

Yep, Google webmaster tools have been leveraged.

The argument that they are making is that people are starting to choose dynamic languages because of "clumsy type systems". Since every relationship has to be spelled out in excruciating detail you spend a ton of time changing and tweaking these relationships. Implicit interfaces, in theory, address this problem.