9 ms·

I'm sure I'm going to get piled on here, but whatever. I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on

by EpicEng 10y ago

I'm sure I'm going to get piled on here, but whatever. I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. "This framework's the best!" "No, this one is obviously better!" "My design pattern is better than your design pattern!" I don't know, maybe I'm a 32 year old curmudgeon, but I just don't see this in my area. I work at a lower level; robotics, image processing/analysis, and general systems level stuff. We worry about what technologies we use for a given task as far as it impacts our design goals, i.e., "which technology is best suited for the job" (and there are more options nowadays than there used to be). Our customers couldn't care less about how we got there as long as the final product kicks ass. Once we arrive at a conclusion we move on and spend the remaining 99% of development solving actual problems. Hard problems. Often times unsolved problems. Our number one priority is reliability and accuracy (ok, that's two priorities). Whether or not we used e.g. C++ or Python to do it is irrelevant. What matters is that we built a system which works as it is supposed to and was engineered correctly. I don't understand this 'programming for programming's sake' mentality. At the end of the day these are just tools, not an end goal. Help me to understand.

hliyan 10y ago
As a 36 year old curmudgeon, I agree. I think the overabundance of framework/tool choices is resulting in decision paralysis. The C++ world doesn't (or at least it didn't) have this problem -- there's usually few standard ways to do something and it takes a only a few minutes to pick one. The rest of developer energies are spent on actual implementation.
kinkdr 10y ago
> Help me to understand. Human nature, maybe? People seem to like to form groups based on some random similarity (supporting the same football team, driving the same car model, believing in the same religion, being of the same race, etc..) and start fighting the opposite groups. My favorite example is the following trivia from the "Planet of the Apes" movie: "During breaks in filming, actors made up as different ape species tended to hang out together, gorillas with gorillas, orangutans with orangutans, chimps with chimps. It wasn't required, it just naturally happened."
- EpicEng 10y ago
  Fair enough, I just wish those same people would spend more of their time building the next big thing instead of telling others how they use the current big thing.
force_reboot 10y ago
Let me explain. You are looking from the outside at a community which has a lot of issues around languages, tooling and frameworks for complex historical and technical reasons. E.g. Things that developed over long periods of time, like desktop apps, had to be rebuilt in the browser in a decade. Ask any desktop application developer how fun they think client side web dev is in comparison. And you are then assuming that the difficulties of this community are because they are immature and not as wise as you. Hope that clarifies things.
- EpicEng 10y ago
  >Hope that clarifies things No, not really, and I don't think I assumed that at all. I think it is objectively true that debating the merits of e.g. Python v Ruby for years on end is an utter waste of time. This is not engineering, it's vanity. I can get behind the occasional spirited debate. Of course there are pros and cons to every tool, and we should know what those are, but at the end of the day that's all they are; tools. They're middle men in the problem solving process, not the end result. BTW, your current web protocols and frameworks are going to change again, just like your decrepit old desktop technologies did. Be prepared to denounce your current toolset and fervently embrace another in the near future.
  - raarts 10y ago
    I think it 's because of the number of young/unexperienced developers in the field. Those are the ones spending (wasting) a lot of time debating the relative merits of frameworks, languages, editors. More experienced people don't care as much.
    - jonathankoren 10y ago
      >I think it 's because of the number of young/unexperienced developers in the field. I honestly think this is it. Webdev has an inordinate amount of "let's rewrite it... again!" But the thing that really cinched the webdev community isn't ready for primetime was the whole left-pad debacle. Auto updating of dependencies is bush league bullshit, and the whole rotten edifice came predictably crashing down because of it.
themgt 10y ago
What is the average number of hours you spend on a given project? Honestly I think part of the reliance and importance placed on frameworks is that a lot of web dev (especially contract/freelance work) is still relatively small projects, stuff between 10-100 hours of work. So you're almost never spending 99% of your time solving unsolved, hard problems. You're building custom solutions to relatively common but special-snowflake problems. And in that context, you need a framework because in effect you're building a 1000 hour project but only spending 40 hours doing some configuration, customization and polish on top of a framework. Could you spend 1000 hours and build something from scratch and forget a framework? Sure, but no one wants to pay for that. So the framework you use is the giant's shoulders you stand on. Rails didn't beat PHP and Java for webdev because hipsters think it's cool. It's because developers delivered projects better and faster with Rails, because it lets you spend less time re-solving the same solved problems which still comprise a lot of modern web development.
- EpicEng 10y ago
  >What is the average number of hours you spend on a given project? That's a fair point; my project plans are usually measured in years, not hours. Of course there is ongoing maintenance, but that's not where I spend most of my time. I didn't mean to imply that tools aren't important, or that we shouldn't care. We absolutely should care, and I do as well. The difference is that I don't feel the need to spend copious amounts of time defending my tools, or debating their merits with other people who will never agree with me. I evaluate them, use them, and move on. They are an integral part of my process, but not nearly as important as building something that solves real problems. It's the same old issue of religion v enthusiasm, belief v fanaticism. That line gets crossed too often and it's just a waste. I think some lose sight of what's important.
  - singlow 10y ago
    Part of the reason it matters more to web developers is that often our clients and employers do care what we use and if we love a particular tool it needs widespread adoption to be able to use it on real work. I have potential clients asking constantly if I can build their project with WordPress or Rails or Drupal or Symphony or whatever else they think is the best. It would be much better if they just came and asked if I could build it and let me help them determine what is the best platform for their project and pre-existing skill set. Now, sometimes, they have a legitimate need to have it integrate with a larger system and using that tool has external advantages. But most of the time it is just a vague notion that if it is in WordPress it will be easy to use, cause you know, anyone can edit a WordPress site. But when you bolt a hundred plugins and custom business logic into WordPress, it makes no difference that it has any easy blog editor. That should have been a separate project to begin with. Half the time they have built 10% of what they need with a dozen plugins, think they are 90% done and that I can just make the rest of it work. This because someone told them there were plugins that could do everything they needed in WordPress and with WordPress they'd get good SEO. The point is that if we want to use a particular tool, we better evangelize for it, because clients never want something built in a framework they haven't heard of. It's not even irrational for the clients, since 50% of the time their developers disappear before the project is done and they have to find someone else who can pick it up and finish.
jasonpeacock 10y ago
FTFY: "I don't understand why those who spend most of their time __using tools__ focus so much on the tools they use to do it." It should be more self-evident now. When there are many tools which meet the minimum requirements for doing a job, then the focus becomes not on which tool can do the job, but which tool you feel does the job the best (or you enjoy using). Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker. You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.
- EpicEng 10y ago
  >You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that. True, but I do my homework too. My code needs to be maintainable for the next guy. We can't invest inordinate amounts of time on V2 where it isn't necessary. I don't want unrelated parts of the program breaking because I fix a bug. The next set of features should be easy to implement from an architectural perspective. All of this is important to the customer and my business. I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.
  - lmm 10y ago
    > I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time. Sure, but that line is in a different place depending on how important the tools are. If you're doing a project where the functionality is 40% custom code and 60% tooling, that will naturally give you a very different attitude to a project where the functionality is 1% custom code and 99% tooling.
- jeffdavis 10y ago
  "Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker." Is that actually true? I can't think of a single example of such an argument. I have heard recommendations, and heard various trendy tools being promoted (at least for music), but never an argument. I think it has to do with transferability of skill. In music, carpentry, and painting, skill readily transfers to different tools even if it causes annoyance or a stylistic change in the result. The stakes are much higher for web development; at least that's the perception. Skills probably transfer better than people think, but it's scary to have 10 years of experience and a high billing rate and then go back to "hello world". It's much more comfortable to try to promote what you already know so that you don't have to do that. And it also avoids wasting time on a new framework that seems promising but never gets critical mass.
dwd 10y ago
I think the problem is no one seriously reads Hawryszkiewycz anymore. Seems everyone's trying to squeeze problems into fitting their solution/framework rather the other way around.
blub 10y ago
Web development is a bit like runaway sexual selection, but instead of developing extravagant plumage, webdevs develop extravagant frameworks and strive to rewrite everything in JavaScript. Blog posts are a way of status signaling but also of fitness signaling. People that have the capability of always learning new things and writing about them should be really good programmers while lower quality individuals can't afford to keep up and drop out of the game. Only the former are able to reliably secure mates and reproduce, thereby perpetuating the cycle.
- bbcbasic 10y ago
  The true alpha of the group will build his or her own framework or transpiler.
- davidgl 10y ago
  What a great comment, I wish I could up vote this 1000 times !
- matt4077 10y ago
  And this rambling indecision of an article kinda leaves me staring into the distance, rethinking some priorities.
dave2000 10y ago
There are no hard problems in web design, other than that browsers are a really shitty platform for delivering software, and there's never been a concerted effort to start from scratch and solve it properly once. Just loads of proprietary solutions which are security nightmares and poorly supported, and endless frameworks. Start again. Burn it all down, and do it properly this time.
pbowyer 10y ago
> I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. Because writing web apps / CRUD apps is soul-destroying, boring, and always perceived by the client as easy (no matter how much business value they bring) so there's pressure to do them fast, as others have said. Any distraction is welcome, and any framework that makes the task less painful is welcome. Both of which foster this fairly pointless set of discussions :) 32 year old curmudgeon here, in the middle of a large web app project...
tluyben2 10y ago
I work in embedded, web & app dev and for web or app dev, by far most customers really don't care what it is written in. They care about the end result only. So we can use whatever is the closest to the endresult already and that's not often something like Rails. More often than not it is actually Wordpress; someone in this thread mentions web projects are more often <100 hours than years (for embedded we think in years, web/apps in 1-3 months) that's why WP is working; our clients do not actually care about maintainability because it's a quick write and will be thrown away / replaced when it served it's purpose.
scotty79 10y ago
Web development doesn't have many hard problems. It has one serious though. How not to get tangled in your own mess when customer is breathing down your neck. Almost every language provides you with sufficient tools for writing algorithms, doing calculations, storing and accessing data, but almost none gives you solutions for avoiding mess. There are many ideas on how to avoid mess but none of them works and people are left to their own devices to figure out how not to get lost. That's why webdevelopers are so fascinated with frameworks. They promise solution to their one hard problem. And some even deliver it to a degree.
- rgbrgb 10y ago
  > Web development doesn't have many hard problems. It has one serious though. Kind of a strange way to put it but I think I agree with the gist. Scaling is the web's hard problem. Building an ever expanding list of features while measuring if users like them and delivering them via cheap computers and tiny pipes is surprisingly difficult. Scaling a rigidly defined web system on it's own generally isn't so hard at this point. One off Twitter clones with a few of T's killer features can be knocked out in a few days with pretty good load scaling properties. But scaling the codebase and architecture from 1 dev, 0 users, and 1 OK feature to XXX users and YYY features users love is really hard to get right. Ideally the 100th feature is as easy as the 10th and you can just add more engineer hours, but more commonly it seems to get exponentially harder to add features as the codebase expands.
  - Retric 10y ago
    Systems always get more complex as you add features. At best you can avoid shooting yourself in the foot, but that's ok because none of your competitors can avoid the same issues.
    - rgbrgb 10y ago
      The web's hard problem is dealing with that complexity at a speed and scale that is a few orders of magnitude bigger than any other programming environment I can think of. > At best you can avoid shooting yourself in the foot At best we can keep our systems simple, agile, and cut bad features as quickly as we test new ones (every damn day!).
fieryeagle 10y ago
Not from me, you aren't. I'm an old soldier in this game (by webdev standards of 6 months for a new framework) and I have tended to switch over to the latest stuff almost every year (projects, job change etc). It's just a common disease and herd mentality in this field to sling the latest cools. Our productivity is generally shit because instead of cranking out working code, we try to fit more tools to the box, probably to combat the repetitiveness and boredom. At the end of the day, it doesn't matter what language or frameworks we use, things still get fucked up because we never spend enough time to know the ins and outs of our tools.
gohrt 10y ago
It's certainly a luxury to not have to think about malicious input from the world wide web, and be able to try any tool you want and just try again if it misbehaves -- it won't empty your users' bank accounts. > I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. > We worry about what technologies we use for a given task as far as it impacts our design goals I don't see the difference.
dagw 10y ago
As someone who spends most of his time on "Hard Problems" but has done a fair share of web apps/CRUD apps I have to admit that web apps are deceptively hard. While going from zero to working prototype web app is trivial in any language, going from working prototype to fully secured, fast, scalable site that is easy to maintain, extend and deploy and easy to use across all devices and browsers is a massive pain in the ass and the difference between the right tool and the wrong tool can easily be an order of magnitude or more in time. Combine this with the fact that the time budget in most web projects is tiny, and the difference in tool choice can really make or break a project. Basically stuff like Image Processing is trivial from an software design/architecture point of view since it's 90+% math and computer science so the the software 'architecture' tools don't matter. Non-trivial web apps on the other hand are 90+% an architecture problem so there those tools matter a great deal.
scandox 10y ago
They're not arguing about technology as such, they're arguing about productivity. The specific problems are not hard, just the organisation and maintenance of the parts. So it does probably matter a lot for this kind of work.

by EpicEng 10y ago

hliyan 10y ago

As a 36 year old curmudgeon, I agree. I think the overabundance of framework/tool choices is resulting in decision paralysis. The C++ world doesn't (or at least it didn't) have this problem -- there's usually few standard ways to do something and it takes a only a few minutes to pick one. The rest of developer energies are spent on actual implementation.

kinkdr 10y ago

> Help me to understand. Human nature, maybe? People seem to like to form groups based on some random similarity (supporting the same football team, driving the same car model, believing in the same religion, being of the same race, etc..) and start fighting the opposite groups. My favorite example is the following trivia from the "Planet of the Apes" movie: "During breaks in filming, actors made up as different ape species tended to hang out together, gorillas with gorillas, orangutans with orangutans, chimps with chimps. It wasn't required, it just naturally happened."

EpicEng 10y ago
Fair enough, I just wish those same people would spend more of their time building the next big thing instead of telling others how they use the current big thing.

force_reboot 10y ago

Let me explain. You are looking from the outside at a community which has a lot of issues around languages, tooling and frameworks for complex historical and technical reasons. E.g. Things that developed over long periods of time, like desktop apps, had to be rebuilt in the browser in a decade. Ask any desktop application developer how fun they think client side web dev is in comparison. And you are then assuming that the difficulties of this community are because they are immature and not as wise as you. Hope that clarifies things.

EpicEng 10y ago
>Hope that clarifies things No, not really, and I don't think I assumed that at all. I think it is objectively true that debating the merits of e.g. Python v Ruby for years on end is an utter waste of time. This is not engineering, it's vanity. I can get behind the occasional spirited debate. Of course there are pros and cons to every tool, and we should know what those are, but at the end of the day that's all they are; tools. They're middle men in the problem solving process, not the end result. BTW, your current web protocols and frameworks are going to change again, just like your decrepit old desktop technologies did. Be prepared to denounce your current toolset and fervently embrace another in the near future.
- raarts 10y ago
  I think it 's because of the number of young/unexperienced developers in the field. Those are the ones spending (wasting) a lot of time debating the relative merits of frameworks, languages, editors. More experienced people don't care as much.
  - jonathankoren 10y ago
    >I think it 's because of the number of young/unexperienced developers in the field. I honestly think this is it. Webdev has an inordinate amount of "let's rewrite it... again!" But the thing that really cinched the webdev community isn't ready for primetime was the whole left-pad debacle. Auto updating of dependencies is bush league bullshit, and the whole rotten edifice came predictably crashing down because of it.

themgt 10y ago

What is the average number of hours you spend on a given project? Honestly I think part of the reliance and importance placed on frameworks is that a lot of web dev (especially contract/freelance work) is still relatively small projects, stuff between 10-100 hours of work. So you're almost never spending 99% of your time solving unsolved, hard problems. You're building custom solutions to relatively common but special-snowflake problems. And in that context, you need a framework because in effect you're building a 1000 hour project but only spending 40 hours doing some configuration, customization and polish on top of a framework. Could you spend 1000 hours and build something from scratch and forget a framework? Sure, but no one wants to pay for that. So the framework you use is the giant's shoulders you stand on. Rails didn't beat PHP and Java for webdev because hipsters think it's cool. It's because developers delivered projects better and faster with Rails, because it lets you spend less time re-solving the same solved problems which still comprise a lot of modern web development.

EpicEng 10y ago
>What is the average number of hours you spend on a given project? That's a fair point; my project plans are usually measured in years, not hours. Of course there is ongoing maintenance, but that's not where I spend most of my time. I didn't mean to imply that tools aren't important, or that we shouldn't care. We absolutely should care, and I do as well. The difference is that I don't feel the need to spend copious amounts of time defending my tools, or debating their merits with other people who will never agree with me. I evaluate them, use them, and move on. They are an integral part of my process, but not nearly as important as building something that solves real problems. It's the same old issue of religion v enthusiasm, belief v fanaticism. That line gets crossed too often and it's just a waste. I think some lose sight of what's important.
- singlow 10y ago
  Part of the reason it matters more to web developers is that often our clients and employers do care what we use and if we love a particular tool it needs widespread adoption to be able to use it on real work. I have potential clients asking constantly if I can build their project with WordPress or Rails or Drupal or Symphony or whatever else they think is the best. It would be much better if they just came and asked if I could build it and let me help them determine what is the best platform for their project and pre-existing skill set. Now, sometimes, they have a legitimate need to have it integrate with a larger system and using that tool has external advantages. But most of the time it is just a vague notion that if it is in WordPress it will be easy to use, cause you know, anyone can edit a WordPress site. But when you bolt a hundred plugins and custom business logic into WordPress, it makes no difference that it has any easy blog editor. That should have been a separate project to begin with. Half the time they have built 10% of what they need with a dozen plugins, think they are 90% done and that I can just make the rest of it work. This because someone told them there were plugins that could do everything they needed in WordPress and with WordPress they'd get good SEO. The point is that if we want to use a particular tool, we better evangelize for it, because clients never want something built in a framework they haven't heard of. It's not even irrational for the clients, since 50% of the time their developers disappear before the project is done and they have to find someone else who can pick it up and finish.

jasonpeacock 10y ago

FTFY: "I don't understand why those who spend most of their time __using tools__ focus so much on the tools they use to do it." It should be more self-evident now. When there are many tools which meet the minimum requirements for doing a job, then the focus becomes not on which tool can do the job, but which tool you feel does the job the best (or you enjoy using). Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker. You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.

EpicEng 10y ago
>You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that. True, but I do my homework too. My code needs to be maintainable for the next guy. We can't invest inordinate amounts of time on V2 where it isn't necessary. I don't want unrelated parts of the program breaking because I fix a bug. The next set of features should be easy to implement from an architectural perspective. All of this is important to the customer and my business. I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.
- lmm 10y ago
  > I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time. Sure, but that line is in a different place depending on how important the tools are. If you're doing a project where the functionality is 40% custom code and 60% tooling, that will naturally give you a very different attitude to a project where the functionality is 1% custom code and 99% tooling.
jeffdavis 10y ago
"Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker." Is that actually true? I can't think of a single example of such an argument. I have heard recommendations, and heard various trendy tools being promoted (at least for music), but never an argument. I think it has to do with transferability of skill. In music, carpentry, and painting, skill readily transfers to different tools even if it causes annoyance or a stylistic change in the result. The stakes are much higher for web development; at least that's the perception. Skills probably transfer better than people think, but it's scary to have 10 years of experience and a high billing rate and then go back to "hello world". It's much more comfortable to try to promote what you already know so that you don't have to do that. And it also avoids wasting time on a new framework that seems promising but never gets critical mass.

dwd 10y ago

I think the problem is no one seriously reads Hawryszkiewycz anymore. Seems everyone's trying to squeeze problems into fitting their solution/framework rather the other way around.

blub 10y ago

Web development is a bit like runaway sexual selection, but instead of developing extravagant plumage, webdevs develop extravagant frameworks and strive to rewrite everything in JavaScript. Blog posts are a way of status signaling but also of fitness signaling. People that have the capability of always learning new things and writing about them should be really good programmers while lower quality individuals can't afford to keep up and drop out of the game. Only the former are able to reliably secure mates and reproduce, thereby perpetuating the cycle.

bbcbasic 10y ago
The true alpha of the group will build his or her own framework or transpiler.
davidgl 10y ago
What a great comment, I wish I could up vote this 1000 times !
matt4077 10y ago
And this rambling indecision of an article kinda leaves me staring into the distance, rethinking some priorities.

dave2000 10y ago

There are no hard problems in web design, other than that browsers are a really shitty platform for delivering software, and there's never been a concerted effort to start from scratch and solve it properly once. Just loads of proprietary solutions which are security nightmares and poorly supported, and endless frameworks. Start again. Burn it all down, and do it properly this time.

pbowyer 10y ago

> I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. Because writing web apps / CRUD apps is soul-destroying, boring, and always perceived by the client as easy (no matter how much business value they bring) so there's pressure to do them fast, as others have said. Any distraction is welcome, and any framework that makes the task less painful is welcome. Both of which foster this fairly pointless set of discussions :) 32 year old curmudgeon here, in the middle of a large web app project...

tluyben2 10y ago

I work in embedded, web & app dev and for web or app dev, by far most customers really don't care what it is written in. They care about the end result only. So we can use whatever is the closest to the endresult already and that's not often something like Rails. More often than not it is actually Wordpress; someone in this thread mentions web projects are more often <100 hours than years (for embedded we think in years, web/apps in 1-3 months) that's why WP is working; our clients do not actually care about maintainability because it's a quick write and will be thrown away / replaced when it served it's purpose.

scotty79 10y ago

Web development doesn't have many hard problems. It has one serious though. How not to get tangled in your own mess when customer is breathing down your neck. Almost every language provides you with sufficient tools for writing algorithms, doing calculations, storing and accessing data, but almost none gives you solutions for avoiding mess. There are many ideas on how to avoid mess but none of them works and people are left to their own devices to figure out how not to get lost. That's why webdevelopers are so fascinated with frameworks. They promise solution to their one hard problem. And some even deliver it to a degree.

rgbrgb 10y ago
> Web development doesn't have many hard problems. It has one serious though. Kind of a strange way to put it but I think I agree with the gist. Scaling is the web's hard problem. Building an ever expanding list of features while measuring if users like them and delivering them via cheap computers and tiny pipes is surprisingly difficult. Scaling a rigidly defined web system on it's own generally isn't so hard at this point. One off Twitter clones with a few of T's killer features can be knocked out in a few days with pretty good load scaling properties. But scaling the codebase and architecture from 1 dev, 0 users, and 1 OK feature to XXX users and YYY features users love is really hard to get right. Ideally the 100th feature is as easy as the 10th and you can just add more engineer hours, but more commonly it seems to get exponentially harder to add features as the codebase expands.
- Retric 10y ago
  Systems always get more complex as you add features. At best you can avoid shooting yourself in the foot, but that's ok because none of your competitors can avoid the same issues.
  - rgbrgb 10y ago
    The web's hard problem is dealing with that complexity at a speed and scale that is a few orders of magnitude bigger than any other programming environment I can think of. > At best you can avoid shooting yourself in the foot At best we can keep our systems simple, agile, and cut bad features as quickly as we test new ones (every damn day!).

fieryeagle 10y ago

Not from me, you aren't. I'm an old soldier in this game (by webdev standards of 6 months for a new framework) and I have tended to switch over to the latest stuff almost every year (projects, job change etc). It's just a common disease and herd mentality in this field to sling the latest cools. Our productivity is generally shit because instead of cranking out working code, we try to fit more tools to the box, probably to combat the repetitiveness and boredom. At the end of the day, it doesn't matter what language or frameworks we use, things still get fucked up because we never spend enough time to know the ins and outs of our tools.

gohrt 10y ago

It's certainly a luxury to not have to think about malicious input from the world wide web, and be able to try any tool you want and just try again if it misbehaves -- it won't empty your users' bank accounts. > I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. > We worry about what technologies we use for a given task as far as it impacts our design goals I don't see the difference.

dagw 10y ago

As someone who spends most of his time on "Hard Problems" but has done a fair share of web apps/CRUD apps I have to admit that web apps are deceptively hard. While going from zero to working prototype web app is trivial in any language, going from working prototype to fully secured, fast, scalable site that is easy to maintain, extend and deploy and easy to use across all devices and browsers is a massive pain in the ass and the difference between the right tool and the wrong tool can easily be an order of magnitude or more in time. Combine this with the fact that the time budget in most web projects is tiny, and the difference in tool choice can really make or break a project. Basically stuff like Image Processing is trivial from an software design/architecture point of view since it's 90+% math and computer science so the the software 'architecture' tools don't matter. Non-trivial web apps on the other hand are 90+% an architecture problem so there those tools matter a great deal.

scandox 10y ago

They're not arguing about technology as such, they're arguing about productivity. The specific problems are not hard, just the organisation and maintenance of the parts. So it does probably matter a lot for this kind of work.