5 ms·

I agree that software development has become (often) pointlessly over complicated in the past few years. For my personal projects I usually develop in Yii2, va

I agree that software development has become (often) pointlessly over complicated in the past few years. For my personal projects I usually develop in Yii2, vanilla JS, SCSS, on MAMP. Source lives in Git, deploy via FTP. I track my progress on a simple kanban. I can push out really complex web applications in days. At work, currently we use headless Drupal 8 as an API layer, React/Angular frontend, automated deployments via Jenkins (that takes over 30 minutes), silly microservices, an over complicated Git strategy, with over complicated Jira/Confluence steps, security scans, pen testing. It takes months to release anything. They're two different approaches, one is quick and "dirty", the other is "enterprise", but the end result is the same: a website. The biggest difference is the amount of time and the cost.

williamdclt 7y ago
I could also edit live on my production server and the result would be the same: a website. I'm not saying that modern stacks aren't more complicated than they need, but I use a React frontend, a React-Native app, silly microservices, a non-trivial git strategy, non-trivial Trello steps, security scans, automated deployment via CircleCI and yet release multiple times a day. The biggest difference is that deployment always works, always passes tests, does not depends on who deploys, rollbacks automatically if healthchecks fail... You know, the sort of stuff that "reduces defects", "builds quality in", "fails fast" and all sort of concepts that people way smarter than us, working in industry way more mature than ours, have been elaborating for decades
- james_s_tayler 7y ago
  Yup. I think people forget that things aren't the way they used to be because we made forward progress. Maybe that means things got more complex. It also means more things became possible and it became possible to not have things happen which you wish didn't. If everything worked so fine and dandy in the good old days, we'd still be there.
  - mettamage 7y ago
    > If everything worked so fine and dandy in the good old days, we'd still be there. I'm not a historian, but I'm pretty sure a historian could find a lot of counter examples to statements like this. That includes historians who know an aweful lot about programming languages.
    - Enginerrrd 7y ago
      Oh yeah. Take consumer goods got example: A straight razor or double edge safety razor and a bar of soap work an awful lot better, cost the customer significantly less, and produce far less waste than modern mass-produced shaving convenience goods at the expense of greater initial costs and a modest increase in required skillset. A fountain pen with a hand-tuned gold nib is refillable and can last nearly a lifetime with proper use. It also requires good writing technique which will reduce fatigue and enhance legibility. I've yet to find a modern can opener that is remotely usable with any kind of longevity. Instead I keep a couple of swiss army knives in my drawer that always just work, and are faster and are easier to clean than any modern can opener I've tried. Hand-made leather boots can be resoled several times and last a decade or more. All of these things have the same common themes: They were hard to mass-manufacture or sell in quantities as large as mass-manufactured goods, they require a bit more upfront costs to use, and require a modest skill investment by the consumer so there's a barrier to entry. That last bit though is the sinister one though. Moving to more forgiving implements is better right? Not if it means you never learn proper technique for doing things. Dig through a manual on penmanship from the late 1800's and you'll find a wealth of valuable knowledge that can help you write neater and with almost no fatigue even with a modern ball-point pen. Curiously, we don't get lessons even close to that in school today. How's this relevant? Take these attitudes and apply them to software development. If you make your tools more forgiving, you can get away with less training for your developers, right?! Less upfront investment in hiring competent developers! Emphasize scale and throughput over quality! ...and all of a sudden, you NEED a bunch of tools to make up for the increase in project complexity of band-aids slapped on top of poor design. And hey, if you slow development to a crawl, you dramatically reduce the frequency of major errors/downtime! Win-win! /s
- invalidusernam3 7y ago
  Don't get me wrong, I'm not saying the quick and dirty approach is better, I'm saying that the end product is very similar. The main difference is the surety that the code is going to work properly when you have checks in place. Complex development processes are worth the hassle for big clients who can't have downtime, but they're not suitable for everything. I would (almost) never bother setting up such complex processes for an after hours side project site because the amount of extra work involved would ensure the project never gets completed.
- colllectorof 7y ago
  Anyone can put a complicated CI/CD pipeline on top of any language, including PHP. What does this have to do with the amount of hoops certain languages force their users to jump through just to see some dynamic content?
weberc2 7y ago
> They're two different approaches, one is quick and "dirty", the other is "enterprise", but the end result is the same: a website. I would say one is appropriate for simple CRUD websites and the other is appropriate for more complicated web apps. Especially as you scale (your engineering organization or your traffic), things like microservices become increasingly useful.
rawoke083600 7y ago
"vanilla JS" - yea that is a big no-no for me these days.. I'm not a fanboy of frameworks, but I would not touch a project without some "published framework". If you DON'T pick/use a framework.. you STILL are using a framework. Just a framework that YOU invented, that doesn't come with documentation, examples, best practises and 1000 questions on StackOverflow. Ever worked on a JQuery project with more than 3 people or one that took longer than 6 months !? Its a nightmarish mesh !! Since there are no std ways todo stuff. Thats what the frameworks gives you, documentation, examples, Q&A and std practises (some are even best practises). I'm sure once you start asking around for the experts and their opinion they will tell you why the framework xyz is wrong but honestly at least everyone on the team and the poor consultants that comes after you, can be "consistently wrong" and know where to jump into this project. Rant-over sorry :) But "VanillaJS and/Or Clean Jquery" Yea no just no. Php: Yea its a mess but a simple mess to get going :) As per first comment.
- lhorie 7y ago
  I keep hearing this "no framework == homegrown framework" argument and it's starting to feel overused and, frankly, not indicative of reality. I find that there's a lot of resume padding when it comes to the web industry and "modern stacks" these days. My job involves managing a large monorepo, and I'm in contact with dozens of projects and teams daily. From my experience, I found that when people actually inherit someone else's React thing, it typically agonizes a slow death with minimal amounts of updates until it finally gets thrown out or rewritten. Also, I've seen some seriously over-engineered stuff that honestly just boiled down to 95% static content and a handful of dynamic elements (e.g. some form validation). Many of these don't need to be a SPA and often can be architected to require very little JS in the first place. When people say they use vanilla js, the assumption should not be that they have the same amount of JS code that a React codebase does: it typically means that the vast majority of what would be React code is simply not written in JS at all.
mytailorisrich 7y ago
Not software development in general but web development in particular. My cynical take on this is that web development is relatively simple so that the 'masses' of web developers funded by the billions poured into web startups, whose products are also often relatively simple technically-speaking, need to create work.

williamdclt 7y ago

I could also edit live on my production server and the result would be the same: a website. I'm not saying that modern stacks aren't more complicated than they need, but I use a React frontend, a React-Native app, silly microservices, a non-trivial git strategy, non-trivial Trello steps, security scans, automated deployment via CircleCI and yet release multiple times a day. The biggest difference is that deployment always works, always passes tests, does not depends on who deploys, rollbacks automatically if healthchecks fail... You know, the sort of stuff that "reduces defects", "builds quality in", "fails fast" and all sort of concepts that people way smarter than us, working in industry way more mature than ours, have been elaborating for decades

james_s_tayler 7y ago
Yup. I think people forget that things aren't the way they used to be because we made forward progress. Maybe that means things got more complex. It also means more things became possible and it became possible to not have things happen which you wish didn't. If everything worked so fine and dandy in the good old days, we'd still be there.
- mettamage 7y ago
  > If everything worked so fine and dandy in the good old days, we'd still be there. I'm not a historian, but I'm pretty sure a historian could find a lot of counter examples to statements like this. That includes historians who know an aweful lot about programming languages.
  - Enginerrrd 7y ago
    Oh yeah. Take consumer goods got example: A straight razor or double edge safety razor and a bar of soap work an awful lot better, cost the customer significantly less, and produce far less waste than modern mass-produced shaving convenience goods at the expense of greater initial costs and a modest increase in required skillset. A fountain pen with a hand-tuned gold nib is refillable and can last nearly a lifetime with proper use. It also requires good writing technique which will reduce fatigue and enhance legibility. I've yet to find a modern can opener that is remotely usable with any kind of longevity. Instead I keep a couple of swiss army knives in my drawer that always just work, and are faster and are easier to clean than any modern can opener I've tried. Hand-made leather boots can be resoled several times and last a decade or more. All of these things have the same common themes: They were hard to mass-manufacture or sell in quantities as large as mass-manufactured goods, they require a bit more upfront costs to use, and require a modest skill investment by the consumer so there's a barrier to entry. That last bit though is the sinister one though. Moving to more forgiving implements is better right? Not if it means you never learn proper technique for doing things. Dig through a manual on penmanship from the late 1800's and you'll find a wealth of valuable knowledge that can help you write neater and with almost no fatigue even with a modern ball-point pen. Curiously, we don't get lessons even close to that in school today. How's this relevant? Take these attitudes and apply them to software development. If you make your tools more forgiving, you can get away with less training for your developers, right?! Less upfront investment in hiring competent developers! Emphasize scale and throughput over quality! ...and all of a sudden, you NEED a bunch of tools to make up for the increase in project complexity of band-aids slapped on top of poor design. And hey, if you slow development to a crawl, you dramatically reduce the frequency of major errors/downtime! Win-win! /s
invalidusernam3 7y ago
Don't get me wrong, I'm not saying the quick and dirty approach is better, I'm saying that the end product is very similar. The main difference is the surety that the code is going to work properly when you have checks in place. Complex development processes are worth the hassle for big clients who can't have downtime, but they're not suitable for everything. I would (almost) never bother setting up such complex processes for an after hours side project site because the amount of extra work involved would ensure the project never gets completed.
colllectorof 7y ago
Anyone can put a complicated CI/CD pipeline on top of any language, including PHP. What does this have to do with the amount of hoops certain languages force their users to jump through just to see some dynamic content?

weberc2 7y ago

> They're two different approaches, one is quick and "dirty", the other is "enterprise", but the end result is the same: a website. I would say one is appropriate for simple CRUD websites and the other is appropriate for more complicated web apps. Especially as you scale (your engineering organization or your traffic), things like microservices become increasingly useful.

rawoke083600 7y ago

"vanilla JS" - yea that is a big no-no for me these days.. I'm not a fanboy of frameworks, but I would not touch a project without some "published framework". If you DON'T pick/use a framework.. you STILL are using a framework. Just a framework that YOU invented, that doesn't come with documentation, examples, best practises and 1000 questions on StackOverflow. Ever worked on a JQuery project with more than 3 people or one that took longer than 6 months !? Its a nightmarish mesh !! Since there are no std ways todo stuff. Thats what the frameworks gives you, documentation, examples, Q&A and std practises (some are even best practises). I'm sure once you start asking around for the experts and their opinion they will tell you why the framework xyz is wrong but honestly at least everyone on the team and the poor consultants that comes after you, can be "consistently wrong" and know where to jump into this project. Rant-over sorry :) But "VanillaJS and/Or Clean Jquery" Yea no just no. Php: Yea its a mess but a simple mess to get going :) As per first comment.

lhorie 7y ago
I keep hearing this "no framework == homegrown framework" argument and it's starting to feel overused and, frankly, not indicative of reality. I find that there's a lot of resume padding when it comes to the web industry and "modern stacks" these days. My job involves managing a large monorepo, and I'm in contact with dozens of projects and teams daily. From my experience, I found that when people actually inherit someone else's React thing, it typically agonizes a slow death with minimal amounts of updates until it finally gets thrown out or rewritten. Also, I've seen some seriously over-engineered stuff that honestly just boiled down to 95% static content and a handful of dynamic elements (e.g. some form validation). Many of these don't need to be a SPA and often can be architected to require very little JS in the first place. When people say they use vanilla js, the assumption should not be that they have the same amount of JS code that a React codebase does: it typically means that the vast majority of what would be React code is simply not written in JS at all.

mytailorisrich 7y ago

Not software development in general but web development in particular. My cynical take on this is that web development is relatively simple so that the 'masses' of web developers funded by the billions poured into web startups, whose products are also often relatively simple technically-speaking, need to create work.