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.