or a passionate user who had a great experience?! I love finding solutions which require less 'square peg round hole'. Unfortunately, rare these days when piecing together a stack w/ the myriad of platforms/frameworks/etc.
I am willing to pay a little extra for a nice dev/ops experience and simple/easy solutions that doesn't require spending days reading docs and diving into dashboards with thousands of options.
Usually this results in me jumping on new platforms and then abandoning them once they add too much complexity.
Hmmm, people can be "single minded" on delivering a good experience for end users. Our project (DB Browser for SQLite) definitely has developers that are. :)
But maybe it comes down to the fact that many developers simply like over engineered solutions and sprinkle some complexity to often boring problems? Not saying that it's always the case but surely many of us can recollect related stories :)
It reminds me of many systems I've seen where you really need to be a developer of the platform to intuitively make use of it for non-tutorial problems.
I absolutely agree with the premise. People just love building things even when they're not needed. After a while, your ego gets attached to whatever it is you've built and you can't let it go.
I remember working at one place where somebody built a new framework to solve a common problem we all had. He pitched it to all the other devs in a meeting and I remember being confused about it because there was a standard framework that solved the problem already and did it in much simpler and more elegant way. (To be fair to him, this standard functionality was only recently introduced.)
During his presentation, I asked why the standard solution wouldn't work for him. It turns out he wasn't familiar with it. Fair enough, so later I messaged him and showed him the standard way to do it and how much simpler it was. He couldn't be swayed.
He just couldn't accept that his complicated solution wasn't necessary. He constructed scenarios where his idea was needed, even though I saw solutions to those scenarios using the standard framework.
Interestingly enough, one of the scenarios where his custom thing was needed was in some tests he had written where he did some complicated things to set things up. I looked at the tests and even there saw those complicated things weren't necessary! There were ways to simplify what he was doing so that the tests were better written and didn't need his custom tool.
Anyway, he wouldn't be convinced. And because he couldn't be convinced, we got stuck with his solution and saw people continue to work on it, add more functionality to it, fix bugs, etc. All of that work was just a waste of time when we could've relied on a standard solution, which was way more mature and way simpler.
All of this drove me crazy, but I realized that sometimes people are just unable to see simple solutions to problems. Worse, having one complex solution begets more complex solutions elsewhere.
It seems analogous to someone new coming into software development and wondering why their small apps suddenly needs a builder server, docker, kubernetes, airflow, jira, etc... They might have a valid argument but it isn't based on experience.
It's what always kept me away from these systems. So many of them are hopelessly over-engineered to the point where it's often easier to write custom solutions.
Absolutely, it's not a perfect analogy but it's a surprisingly good one.
The value is in the sheer size of the ecosystem and the idea of everything being plug and play, even if the reality often necessitates actual code when you get past the happy demo path to your business's weird edge cases.
I certainly agree with you there. Cutting the Gordian Knot of overly-complex software salad, and deploying only what my customer needs, while keeping it simple and robust, is how I pay my bills.
Absolutely. It strikes me as odd that these days it is not only acceptable, but encouraged as a virtue, for developers to focus on making their own jobs easier as opposed to delivering a good (fast and efficient, among other things) product.
They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything..
Anecdotally, in my 20+ years of working for website and web app companies, I have never had a client who has even suggested a specific way of implementing an app. The closest has been when a client has asked for a tech proposal and had it sanity checked by a third party. These days I mostly work on "rescuing" apps that a client has had built by one company, found it hasn't gone well, and has come to the company I work for to make it work properly. All of the crazy tech stack implementations I've seen have come from developers who think they're clever, and never the client demanding something trendy.
A ridiculously large ecosystem of developers is a huge feature that we ignore at our peril. I think a mature developer should overlook aesthetic quibbles with a language, framework, or any other tool, and make decisions based solely on what's most practical.
I agree and don't really work in this area anyway, but work with brilliant developers who didn't go that route just to add something on their resume. There are obviously tradeoffs and it isn't a silver bullet. Trading one kind of complexity for another may make sense depending on the use.
You just showcased my point! People would spend weeks in search for solutions that implement part of required functionality, instead of using whatever they're most familiar with and move on.
I was wondering how much "elitism" this article might inspire. Not every bit of software needs to be developed through a TDD process using the latest NoSQL database and concurrent programming techniques. Sometimes the 80% (heck, even 40%) solution is all that is required.... Good on this person for taking some initiative.
I don't think that's an issue at all. I get what you're saying though. I know many times I've built something that already exists and whenever it happens my version falls into one of 3 categories:
1. Something that someone else is doing better. Fail.
2. Something someone else is doing exactly the same. DRY/don't reinvent the wheel fail.
3. Something that does something seemingly the same as others but because it adds something others don't.
I think urlbox falls into category 3. There are lots of ways that a new entrant can be successful. Just tailoring it to a specific use-case honestly goes a long way towards success in my book. For example, Blitshot seems to be all about image processing of screenshots in general (and if it's not let's say it is for the sake of example) - you get an API for screenshots and image manipulation and it's up to you to find a use for it. But if someone else enters the fold, like urlbox perhaps, and says "our API is for purpose X and you can only use it in these ways" they could actually be very successful despite not offering what someone else is. There are a lot of people who'd rather use a product with less features in general but whose features are tailored to their use case than another product which offers the same and more but with no specific focus. Look at Pinboard. It's basically Delicious for a specific user group. All it lacks is the social aspect of it which you're not forced to use with Delicious anyway plus Pinboard is far more expensive (anything is "far more" expensive than free). I think Pinboard is a great example even if it doesn't fit exactly.
Or sometimes it's just a missing piece of critical thinking - 'Is what I'm doing unique to me, or is it something other people need to be doing as well?'. Most times there are others doing the same things, and that means there's a market probably being served by someone already that you can leverage to meet your needs.
Or down the other path where that question is never asked is the madness of 'fully customizable' LOB stuff, like SAP or Domino.
I have that conversation often in the enterprise apps space, and so frequently the fundamental question just hasn't been considered while everyone rushes towards a horrible custom code nightmare that's entirely unnecessary.
While I understand where you're coming from, I expect that if you've had to manage application deployment and configuration in a large-scale environment you would be quite aware of how much work it is to develop even a one-off robust solution that is fully tested for edge cases, let alone reusable.
reply