16 ms·

Did you consider that the next developer might well come along and post a similar comment: > It replaced a site that was pretty much a home-grown PHP framework

• TotempaaltJ 7y ago
  And here's the trick to not building shit software: don't build shit software. It's a crude way to put it, but the reality is that you can build bad websites in any framework (including old PHP stuff and new JavaScript hype). You can also build good websites in any framework. It depends way more on the organisation or team developing it than on the libraries you use.
  • afarrell 7y ago
    The trouble is that "don't build shit software" isn't actionable advice on how to avoid building shit software. For someone seeking to be a more skillful web software engineer, there's no information there.
    • justbaker 7y ago
      It means the underlying problem is not the tooling, but the use of the tooling. In other words, "I can choose the correct tool but still fail from poor approach of problem."
      • orf 7y ago
        If the tool allows you to shoot yourself in the face without warning, and has a reputation/history of doing it to a lot of other people, then the tooling is indeed the problem.
        • chrshawkes 7y ago
          Nobody is building anything unique with the same tool. I get your point though. The more handholding these frameworks do, the less we learn it seems.
        • MadWombat 7y ago
          Most tools out there allow you to shoot yourself in the face. In this case, the guy replaced client-side JavaScript (very notorious for its amazing face shooting abilities) with server-side PHP (also, a very notorious face shooter).
          • jdnenej 7y ago
            The real metric of quality is does it do what you expected. PHP is a gun that sometimes shoots backwards with no sensible reason where as rust has a gyroscope that can work out when the gun is pointing at your face and requires that you turn off the safety first. Entire classes of bugs simply don't exist in better languages.
            • MadWombat 7y ago
              Well, yes. You can write a web application in Haskell and enjoy the beautiful and flexible type system, first order functions, monads and all the other wonderful things. But you shouldn't. Because when you leave, the client will never be able to find someone to maintain the damn thing and chances are they will hire someone else to rewrite it yet again in PHP. And possibly hire someone to make a voodoo doll of you and stick pins up its ass.
              • afarrell 7y ago
                You can also write your application in Ruby or Python or Java or Go
      • TAForObvReasons 7y ago
        There's no guarantee that good approaches in 2019 will still be good approaches in 2029 and beyond. OOP was considered a good approach many years ago, and now in many circles it is derided and bashed.
    • void445be54d48a 7y ago
      Just don't build software and then we won't have shit software
      • gen220 7y ago
        I know this was probably meant as tongue-in-cheek, but I think this is a powerful idea. I think it should be a more widespread idea that people should aim to leave a company with a net-negative `cloc` contribution.
        • johnchristopher 7y ago
          Actually, that's a well know mantra: the best code is no code.
          • keithnz 7y ago
            no code is also the fastest thing you can do!
          • BubRoss 7y ago
            People don't know what that means though. It is only helpful after explaining to shoot for deeper yet simpler rules for your system along with identifying what can be separated from execution as static data.
            • Frost1x 7y ago
              Part of that mantra also falls under problem solving in general. Not every solution needs a technology solution. Sometimes fixes can be made in processes or policy in general. Many jump to technology solutions too quickly and I feel this is lazy and often passing responsibility for someone else to fix a situation.
            • johnchristopher 7y ago
              Yep, I can see how beginners or god-level guru could turn that into a thousand characters one-liner.
    • castis 7y ago
      It most certainly is actionable advice, but it's usefulness depends on how well you take blunt advice.
      • enraged_camel 7y ago
        What exactly is actionable about it? Just curious.
        • castis 7y ago
          Google the inverse question "how to build good software" and dont stop reading until you die?
          • SketchySeaBeast 7y ago
            That's like googling "how to eat right" - it's going to be 99% unhelpful and contradictory.
      • chrshawkes 7y ago
        Unhelpful advice. Typical programmer up his own ass bullshit really. Oh that ways not good. Well what's good? I don't know, just not that. Look at how many clowns criticize jQuery these days as an example of garbage software.
        • benbristow 7y ago
          jQuery isn't garbage as per se. It's a great library for directly querying & manipulating the DOM. Trying to make web applications with it is another story though. The lack of any state management is a nightmare, hence declarative frameworks/libraries such as React/Angular(JS)/Vue/Svelte etc. etc. came along.
          • lacampbell 7y ago
            The lack of any state management is a nightmare What makes the lack of state management a nightmare in the javascript world, but a complete non-issue when doing .NET or Qt apps? As someone who started with desktop apps and then moved into web dev, I never really understood why Javascript developers wanted a library to help them manage state.
    • madeofpalk 7y ago
      But "Javascript makes you build shit software" isn't actionable in the sense that its definitely incorrect.
      • gameswithgo 7y ago
        There is some truth to it. The whole ecosystem encourages a lot of things that are bad for developing simple, stable, good performing systems. I don't go anywhere near that world unless I have to for these reasons. You get all the downsides of dynamic language ecosystems, with worse compile times than Rust (webpack etc).
        • rhengles 7y ago
          In my opinion, the biggest complicator there is in javascript land is Webpack and similar loaders. They do absolutely everything in the name of optimizing performance in production, things which even the "development mode" don't simplify. I developed my own custom scaffolding for Vue projects[0], which is a lot simpler and customizable. It even allows you to develop Vue projects without a build step/tool, you save and reload. Yes, there are tools that reload the page when you save, but I don't think they're worth the complexity. It could be further improved to actually compile/build when you actually want to deploy, I hadn't the time or a strong need for it yet. But when you are developing, things need to be simple, I think you need to know everything that is happening in the browser so you can resolve any bug with much more speed and confidence. [0] https://news.ycombinator.com/item?id=20270816 https://news.ycombinator.com/item?id=20270816
        • scarface74 7y ago
          I try to know just enough of the $cool_kids front end stack to pass an interview, but I’m very honest - I don’t like front end development and that’s not my forte. Besides, front end developers are a dime a dozen. Your typical software as a service CRUD company, is looking for mere competence and pays at that rate. I have no interest in competing in a commodity market.
      • cwp 7y ago
        It's not Javascript that makes you write shit software. It's trying to write software that runs correctly on a wide variety of platforms that you don't control. reaperducer's rewrite was an improvement, not because he replaced Javascript with PHP, but because he moved all the logic to the server, which is a single environment he controls. He could have used Node instead of PHP and achieved the same thing.
    • jfaat 7y ago
      Sure but for that person is “use a no-nonsense lamp stack” going to result in a better outcome than them just starting with react?
    • thaumaturgy 7y ago
      This is fundamentally because our industry is built on opinions, not standards. You talk to one software engineer, and they'll say, "that's built in PHP, so it sucks; it should have been built with npm, obviously." Then you talk to another and they say, "I can't believe they built that with npm, the package management system is just terrible and the whole mess is bloated and there have been a ton of security issues. They should have used a static generator instead." And on, and on, and on. Now compare this to a mature industry with real engineers who are able to say things like, "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year." That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Nobody's bothered to do that work. We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects. This is absolutely shameful IMO, and the reason why I cringe a little inside whenever I see the words "software engineer".
      • pfraze 7y ago
        Not that software can't improve on this front, but I'm pretty sure that every engineering profession has its fair share of opinions and disagreements around them. Heck, my dad's a general surgeon and he's constantly debating with other surgeons over things like whether a procedure should be out-patient or which procedure has the best outcomes. They have a better concept of outcomes, which helps them make data-driven decisions, but they also have a higher risk profile which slows down the innovation process. I agree with most of your premise, but I think you overstate it a bit. Like the GP's point above, it seems like you're describing bad engineers. In the good web dev agencies I've worked at, they work pretty hard to make informed decisions which stay within budget and timeline. It doesn't always happen, but that's not just due to poor practice.
      • testy3 7y ago
        There are reasons why other industries are more mature, like: they've been waaaaaaaaay longer than CS/SE they do not change so robustly & fast in short peroids of time. >We can't even accurately estimate the cost of a complex project given our choice of tools Let's do not pretend as if that was limited to our industry.
    • 6gvONxR4sf7o 7y ago
      I think that's the point. If you're looking for actionable advice in terms of "hammers are better than screwdrivers" you aren't going to find it. You'll find people purporting to give that advice. Look elsewhere, like "best practices for hammers" or "when to use a hammer instead of a screwdriver" or better yet "best practices for working as a team."
    • krageon 7y ago
      Build software that you would still want to work on five years later. That usually means tests (that aren't so embroiled in the technical details they break with every trivial change, but instead describe the business logic that is important for your application), sensible abstractions, etc. Usually from there you can select some paradigms that make sense for you. Fundamentally, all of it is a matter of opinion. You have a million options and they are all correct. Don't take a million options at once, practice a lot, understand your problem domain. You won't write something perfect every time but you'll write something a whole lot better than if you were using a million frameworks instead of real thought.
    • cjfd 7y ago
      There may not be actionable advice for someone hiring a software engineer if that person knows nothing about software engineering. However, I would argue that that person is in a bad position no matter what. There is actionable advice for a software engineer here insofar as the general 'shitiness' of software is due to a lack of discipline on the part of the software engineer. Having witnessed inexcusable practices like functions that contain 10000 lines 'don't build shit software' sounds like very much actionable advice to me.
    • hhas01 7y ago
      The key to being a competent software developer is really, really simple: Learn the Business. Because if you can’t/won’t/don’t understand the problem domain, how can you expect to solve problems in it?
  • jorblumesea 7y ago
    Do you think anyone goes into a project thinking: "I'm going to build some complete garbage"? Shifting project and business requirements, scope creep, poor design choices and lack of competence all contribute to what makes bad software.
    • johnisgood 7y ago
      Eh, many people think "let me shit it out ASAP for those quick bucks", and then there it is. I would say not giving a damn about quality is identical to your quote, feels a bit more passive, but still.
  • avgDev 7y ago
    I agree as I build some terrible applications in .Net MVC, which is a decent framework. I think you have to build shit software not to build shit software. First, professional web app I developed 3 years ago is still being build upon now. Even though it is pure garbage and I hate touching it, because I "made it work". As I gained experience and got burned because I did something a certain way I slowly but surely looked for alternative approaches. Now 3 years later, I'm building an app with layered architecture, proper separation of concerns, dependency injection. Plus, before I start hammering code away, I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time? Then, proceed accordingly.
    • ct520 7y ago
      " am I gonna use it once and forget it? " Always comes back to bite me in the a$$. Also taking over projects that were built this way always a pain. Now and days I just refuse to do the work if they pushing to cut corners.All in all I say my quality of life and the sense of being proud of work has increased.
      • avgDev 7y ago
        I do agree with you. Now that I think of it I rarely write "use it once and forget it", because as you said it will come back to bite.
      • benbristow 7y ago
        "am I gonna use it once and forget it?" Isn't the saying, YAGNI (You're not gonna need it)?
        • Izkata 7y ago
          YAGNI is meant for a "this could maybe be useful" scope-creep feature, that seems simple to add but doesn't have a reason to exist. (Aside, flip the contraction to get the acronym - "you aren't gonna need it")
    • JohnBooty 7y ago
  • enraged_camel 7y ago
    >>It's a crude way to put it, but the reality is that you can build bad websites in any framework The point of (well-designed) frameworks is that they act as “rails” and make it difficult to make bad decisions. They also make it easier for people on a team (or people who maintain the project after you leave) reason about your code. Therefore, as far as I’m concerned, not using frameworks is a huge red flag. edit: bring on the downvotes!
  • jeoeo0md 7y ago
    Agreed. Doing things in a computer is just organizing the information you have at hand. That could be files or symbols in files that defined a set of operations a computer should run on symbols in another file/db. This isn’t magic. But it’s susceptible to social behaviors and those are “growth every quarter, demand, demand!” so we latch onto buzzwords or trends because some VC funded dork thinks their way of laying out a todo app is best. IMO anyway. Having gone freelancer and flipped the bird to corporate life, I’m way happier and write little code: not having to learn new frameworks makes when to write more generic, re-useable, dependency less, code way more obvious. And I don’t have to worry about a Github repo going inactive. We’re making it harder with tent pool frameworks due to information overload. When the work is information organization, less is more. A parallel to all that “more data is just a bigger security liability.” theme that popped up a couple years ago. It’s also a progress liability.
  • weberc2 7y ago
    These are strawmen arguments. No one is arguing that libraries matter more than organizations/teams, and no one is arguing that it's impossible to build good/bad frameworks in any given language/framework/etc. You can (and should!) solve the problems with your teams and your tools. If you pick a tool that solves problems you don't have (probably because it's new and shiny), there are probably hidden costs that you didn't consider and you're probably going to slow your team down. How much that slow down is going to affect your project depends on how significant the slow-down is and how sensitive your project is to developer productivity (the widely used internal tool with the big budget at BIG CORP is probably safe, but the team at the small startup with the shoestring budget and fierce competition is going to feel that friction in a bad way.
  • PopeDotNinja 7y ago
    Define shit software.
    • jayess 7y ago
      Whatever the last developer did.
      • PopeDotNinja 7y ago
        That's pretty much the truth.
  • rubicon33 7y ago
    That is THE benefit of a "framework" - It locks you, and future developers, into a paradigm. It might not be a "best" or even "good" way of doing things, but, adopting a framework helps keep everybody writing the same 'shit software'. Consistency, it turns out, is key. That's because (as others have pointed out) all software is ultimately shit software. If you wrote it, chances are you don't think it's shit, but everyone else does.
  • crimsonalucard 7y ago
    What if I told you there is a theory about good module design and if you follow the formal rules of the theory (not design principles mind you there's a huge difference) good and organized designs can emerge from just knowledge of the theory itself?
    • dlcmh 7y ago
      Any material you’d recommend on this subject matter?
  • Aeolun 7y ago
    I’d argue that it depends mostly on the organization. A great developer is still going to produce shit if the organization doesn’t work with them.
• dpau 7y ago
  was just about to comment along these lines! i never understood those eschewing frameworks... in the above example a PHP framework like Laravel is in constant development by lots of people, with security updates and refinements pushed out on a regular basis. even if u are an uber-developer, in what situation is rolling your own ever the right choice? is your project that different from everyone else's?
  • syn0byte 7y ago
    Why don't you drive an 18 wheeler to work every day? They are used by millions of professional people every day who's job it is to drive! Why would you be different from all those people that you think you need to use a little car instead? The answer is obvious in both cases; You don't need it and it would be wasteful. If I don't have a huge database with constant read/write calls, If I don't have to try to manage multiple end users submitting content, if I don't need super async real-time snappy UIs to compete with the latest android app fad or session tracking of tens of thousands of users, why would I need laravel? If nobody rolled their own specifically for what they needed, we would still be writing ASM/APL/Raw hex.
    • dpau 7y ago
      i'm sorry but i'm really not convinced by this argument. there are many frameworks available in various languages/platforms, some created specifically to be light and fast (in the PHP example above, lumen is a possible choice). my other argument would be- why are you spending so much time on plumbing when you could be concentrating on the parts of your application that make it special?
      • NeoBasilisk 7y ago
        Most people are making CRUD apps that aren't all that special.
    • least 7y ago
      This analogy sort of falls apart in the details. Rolling your own is more akin to building your own vehicle. You might have all the right parts to have a functioning vehicle but you probably don't have the experience of a team of engineers and designers of a commercial vehicle. In most cases you can buy a modestly sized vehicle from a manufacturer that still has a team of people ensuring the performance, utility, and safety of the vehicle.
• reaperducer 7y ago
  I'm sure it's possible. Someone may come along who is all into DrupalPress and Agilereactboxqueryhack and think it's primitive. But they won't be able to say it's not maintainable, upgradable, or scalable. And it's documented out the wazoo, all the way down to the CSS both in code and in the accompanying PDFs. The last developer gave zero thought to who would come next. I've given great thought, and included the occasional quotation in the code comments from Goethe where appropriate. But if the company wants to pay him/her to blow away my work, then that's neither my business, nor my problem.
  • Dumblydorr 7y ago
    Wow, awesome! Can you share your Goethe use and the context it enriches?
  • geegoo 7y ago
    There are pros and cons to this. One con is that the next developer might have to spend considerable time buying into your ecosystem to be productive. A pro is that it is easily maintainable by you since you built it; which is also a con since it's not generally feasible for a single developer to cover all the in's and out's of a web ecosystem. Lets say you pass away tomorrow, and a week from now a major security vulnerability is announced that affects your system. If you had used a mature framework (Such as Laravel) with a auto update system in place, the issue might be patched in 1-2 weeks. Whereas in this hypothetical the company has to hire a developer that now has to ramp up on your software, be familiar with the security vulnerability, know how to patch it, and have some guarantee that your system will behave as expected. This puts the burden on both the employer who might not know how to screen the applicants because it's not their domain, and the developer. Saying software is clean because it is untangled from a larger code base is misleading for most use cases, but especially so for web development. It is also not fair to treat front end and backend code in the same context as you can easily decouple both without (since you didn't mention if the backend itself is custom built by you or not, but it seems implied)
    • Roritharr 7y ago
      From my experience, going through a vanilla php app to fix a CVE is a much better experience than praying to the Framework Powers that be to have your patch ready and non-breaking when you need it.
• weberc2 7y ago
  Right, but will they be able to say that the customer was thrilled with their rewrite? Probably not; they're already mostly happy with the simpler site and now they've paid to make things (almost certainly) more complex than they need to be. They probably feel swindled into agreeing to a rewrite of something that was mostly working but The Next Developer told them that adding that new feature would require completely rewriting the front- and backends.
• tluyben2 7y ago
  > but one man's garbage is another man's treasure. Not entirely related, but there is usually the incentive to at least say this for a new person/team coming on because money. Especially for frontends, the new person/team we talk to when going into an existing project, says that it has to be redone because it's 'not up to standards'. That is not because it's not fine and maybe even beautiful; it makes more money to rewrite it. And job security perhaps too. So when someone says something is garbage, I need to assess the reason why; is it garbage or does the person saying it benefit from a rewrite somehow.
• codegeek 7y ago
  Not necessarily. If the new developer rewrites in a modern framework again but the user experience becomes terrible (looking at you modern reddit), then the new developer cannot really say that. As a developer, I understand the hard to update CSS etc but that is far better if the user experience remains great.
• Theodores 7y ago
  > Hard to update CSS. When was the last time you had a go at CSS? So much has changed since 2017. You can chuck out the pre-processor junk and just use CSS variables and CSS Grid. Productivity is 10x. You can even keep it simple so that a page just loads the CSS it needs instead of some 40,000 line ball of junk. Same with templates, if you are using CSS Grid you don't need the sea of div containers, you can just use actual content elements from HTML5 and never use a div. Pseudo-selectors mean you don't need spans. You can get pretty things done without the markup in the document. Once you write HTML this way you wonder what on earth people are doing with these impossible toolchain and impossible HTML web pages. Regular development from about five years ago with frameworks and jQuery nonsense just looks like hacks.
  • Roritharr 7y ago
    Honest Question, how do I support our IE 11 Customers (8% of our MRR) with this approach?
    • Roboprog 7y ago
      Alas, about 50% of mine. Many government and healthcare organizations STILL using Internet Exploder, presumably until its 2025 end of life:-(
      • spaced-out 7y ago
        >presumably until its 2025 end of life Oh you sweet summer child...
        • Roboprog 7y ago
          Wishful thinking? PS - this “child” started working as a developer, at least part time, back in 1985 C++ eventually passed into a bad memory, and so will MSIE.
      • collinmanderson 7y ago
        2025 end of life for IE11? Do you have a source for that? As far as I know, Microsoft plans to keep IE11 around as long as Windows exists.
• BubRoss 7y ago
  If something works well for the business and customers it isn't garbage. Fast websites that don't break are good for everyone.
  • scarface74 7y ago
    Except for the developer who is statistically going to change jobs every two or three years and all of the openings want someone with “$x years of experience with $framework_of_the_day” And the hiring manager who can’t find anyone that doesn’t want to pad their resume for the same reason.
• burlesona 7y ago
  Logic in the templates... are you describing PHP or React? To be fair the parent comment isn’t saying everything about his stack is perfectly elegant, but if you can deliver a website that works without stateful client side JS and associated build tooling, then it certainly is simpler, and most of the time simpler is better.
  • tiborsaas 7y ago
    I'm 90% sure it's Twig (or Jinja in Python land)
• jtdev 7y ago
  ...ORM use <> better code, I’ve actually found the opposite to be true.
  • Roboprog 7y ago
    I would tend to agree. Not a fan of database abuse / contempt. Turn on the SQL trace in Hibernate and weep. So much code wanking to be “performant”, which just waits for horrible database usage to grind along.
• lonelappde 7y ago
  The true judge is the user experience, not the code quality. Modern web sites try to be apps, with tons of whizzy nonsense that breaks on user browsers, to the users' detriment, when they should be simple CRUD sites to manage digital files.
• alistproducer2 7y ago
  As long as the code isn't abstracted more han 1 or two layers deep, it's commented in places where the control flow isn't that intuitive, and follows best practices for whatever the kids of languages is, it doesn't matter if it's home spun. Just being "home grown" is not synonymous with bad software. At the end of the day, just using frameworks are no guarantee that the code is readable and maintainable. Usually by the time someone is looking at your code to rewrite or update it, what seemed like an awesome choice of framework at the time can end up being a nightmare to parse as documentation has dried up, forums that were the sole source of knowledge are offline, and now your once amazing code is just garbage to the poor coder trying to make sense of the random abstractions of the framework.
• flukus 7y ago
  Did you consider that up to a certain point any framework, be it home grown or commonly used, makes things more complicated? Simple cgi endpoints and static files for any css/js should be our starting point and any web developer should understand them. When the problem becomes bigger and more complex is when we should start looking at frameworks.
• tsukikage 7y ago
  > Did you consider that the next developer might well come along and post a similar comment "After me cometh a Builder. Tell him I too have known." http://www.kiplingsociety.co.uk/poems_palace.htm http://www.kiplingsociety.co.uk/poems_palace.htm
  • yrro 7y ago
    Thank you for introducing me to this wonderful poem.
• deleted 7y ago
  [deleted]