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 written by a single developer. Random mixed logic in templates, hard to update CSS and a poorly designed 'not-an-ORM' ORM.
Not to say that your rewrite is like that, but one man's garbage is another man's treasure.
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.
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)
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.
People have been maintaining SW developed by 3rd parties for several decades. Something like 5 or 6, probably. With all the various amount of available documentation you can imagine, and that includes no documentation and really stupid code bases, or even no source code and you have to patch a binary.
So while I recognize it can be obviously cool to e.g. have virtually no code but simply use a well-designed and currently actively-maintained third party project, it is not always possible, and if it's not then implementing (or even just configuring) anything on top of fashionable software can also be done in crappy undocumented ways.
So the key is to actually have detailed and useful documentation, regardless of 3rd party stacks (or they very relative "absence", I mean probably don't develop your own web-server nor your own database nor your own programming language nor your own operating system nor your own web-browser...)
They absolutely can and will say it's all of those things - and for the most part the client will be none the wiser. It's practically the first step in relationship building for most agency pipelines.
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.
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.
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".
Likely in that other industry the engineer built 100+ other basically identical items that are two or three orders of magnitude less complex and where all the costs and techniques are pretty well known.
Also, those mature industries routinely overrun by millions of dollars and months or years, event though they are dealing with a fraction of the complexity and the costs and techniques are well known.
Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries", on top of astronomically complex systems, and estimate it with an accuracy of 5 to 10 days and a few thousand dollars.
What they do to the end user might be different, how the pieces come together, it is always the same, unless one is doing curriculum driven development.
I wish we could get away from the fashion show in this industry. Currently we have a React frontend, which just adds extra complexity for no real benefit. But its fashionable.
React (and other SPAs) may be fashionable, but I generally contend that--when written well or even passably, which obviously requires an asterisk lest the Scotsmen come by but I don't think is a very high bar--if nothing else it requires developers to treat a web application as a client of an API rather than tightly integrating it. It enforces a level of separation of concerns that, IME, tends to encourage loose coupling and better design.
Forget everything about responsiveness or whatever (which I find way more valuable than the tradeoffs one makes)--the lack of tight coupling is the real win of React and similar. I mean, if you'd like you can pretty easily build a server-side React app with NextJS and still get a lot of these benefits while using React purely as a pretty-dang-good templating language.
SPA apps will decouple the backend from the front end, but the front end will always be specific to a backend in the vast majority of cases. I don't see how that is so different from templates being rendered on the server.
Old school server side rendered apps are underrated and its perfectly possible to make something that looks and behaves as well as a SPA app for most things.
I disagree that the frontend will be specific in even a "vast" majority of cases--if only because of the obvious proliferation of mobile. And while I agree that you can often make a good-looking server-side-rendered, templated application, I will contest that you can ever make a server-side-rendered, templated application feel correctly on a mobile device.
Even in the case where you do have a specific frontend, I contend that there's still value in the separation because it very strongly encourages (coupled with tools like, shameless plug, nestjs-data-sec[0]) the writing of very clear viewmodels where thought must be put into what exactly should be exposed over the wire in a way that commingling database objects and template logic doesn't allow.
I think server-side rendered pages are properly rated at this point, not underrated; there are places to use them but they're shrinking as other tooling get better. As an example, even I write React almost exclusively because I write React faster and with fewer errors than any templating language I see in common use except maybe Razor (and Razor implies buying into ASP.NET, which, no). React/TypeScript are hard to get wrong and easy to burn through quickly. And I would call a React page rendered through NextJS a "server-side rendered app"--but I get the feeling you would not. ;)
Off topic this but your phrase "lest the Scotsmen come by" intrigued me. It sounds vaguely idiomatic but I don't know the reference. Any enlightenment available?
90% of apps use databases, but that doesn't mean they are just database frontends. If you zoom in there is always specialized domain logic that is custom to that app. If there isn't it shouldn't have been built.
>Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries", on top of astronomically complex systems, and estimate it with an accuracy of 5 to 10 days and a few thousand dollars.
You are seriously overestimating complexity and novelty of most software development, while underestimating engineering in other industries. I work currently as software developer and previously in a branch of a civil engineering.
Do you seriously think that other engineering disciplines to not have those small little problems that plague us all the time in software development?
They do, but they can offer their solutions based on data, not just whim.
They do also have codified standards, and guidelines and certification exams.
On the other hand software development is relatively new discipline - other fields had hundred of years to mature.
EDIT: and they are catching up with rapid prototyping - it is getting cheaper and faster.
> Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries"
I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge.
> I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge.
That is because you are ignoring/left out the critical last part of the phrase you quoted: "and estimate it with an accuracy of 5 to 10 days and a few thousand dollars."
This is particularly relevant because this is a direct response to the following:
> 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.
It's especially hilarious because he is comparing projects done by bootcamp graduates to projects done by highly trained PhDs. Some people just don't have a clue about the massive difference involved in webdev type projects and complex engineering projects.
>>>>Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries"
There are occasionally novel engineering projects. These will be millions of dollars and years over budget, and then will fail. All their "mature industry standards and procedures and certifications" wont' save them.
It's unwise to extrapolate the US defense industry's procurement problems onto the Russians and Chinese. There's reasonable evidence to suggest the Russian Kinzhal and Zircon hypersonic missiles are already Working As Designed, or fairly close to it.[1][2]
Yeah, I used to hold similar naive views fresh out of school. Reality is, at least 98% of the software out there is just redoing what has been done, copy paste for slightly different purposes, integrating libs in slightly different ways.
But maybe its hard to admit it, lower down your ego and be a bit humble. Yes, software development is a creative work, but so are all other engineering branches. And yes, we have massive issues with code, process and people quality across whole business.
> "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.
Sure they can. At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc. (Actually there were two of them - the more famous one is the Jeff Dean version that traded off CPU cycles vs. L1-L3 cache misses vs. RAM latency vs. sending data over the network vs. compression vs. disk latency etc, measured in nanoseconds) If you had any moderately complex new system, you'd prototype a few different approaches on a small set of sampled data, do some multiplication to figure out how much it'll actually cost in production, then compare that against the engineer time needed for various optimizations. If you were in a revenue-generating area like Search, somebody (usually at the executive level) would also be calculating how much the project was likely to make or lose for the company and ensuring that's acceptable. Not all that unlike any traditional engineering field.
The thing is that the overhead for this process really only makes sense at Google scale. For the vast majority of new software projects, revenues on success >>> developer time >>> hardware cost. So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time. And if the developer can build it, the hardware costs needed to run it will be negligible, so just buy more hardware.
This is an artifact of the software industry essentially being a gold rush, where it's rapidly eating the rest of the world and replacing non-computerized processes that are millions of times slower. When you have 6 orders of magnitude to play with, you can play fast and loose with estimates, because any acceptable solution at all will make you a lot of money. When software has eaten the rest of the world and new systems are competing with existing computerized systems, then it's worth it to start paying attention to things like efficiency, security, TCO. There's some evidence we're approaching that point, but we're not there yet, and it's still more advisable for an entrepreneur to tackle an old-school non-computerized industry than to try and improve on existing software solutions.
> At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc.
Could someone alert Google's web developer teams (in particular the GMail frontend team) about that cheat sheet? If released products are considered as evidence, it doesn't seem like this cheat sheet is used.
I left 5 years ago, but a friend of mine who stayed said that Google's basically given up on trying to hold the line on latency, and recent projects don't care. Which is kinda a damn shame - when we were Nooglers we fought for bytes - but I get the sense that the institutional knowledge about how much latency affects revenue left when Marissa, Amit, Craig, et al departed and Larry & Sergey moved upstairs to Alphabet. Sundar's background is Google Toolbar, Chrome, and Android, all of which are product areas where latency doesn't matter because it's installed desktop software.
Ugh. You've basically made the case for me doing my next project in c++ 17 instead of using it as an excuse to learn Rust. Im morally opposed to c++....
In C++'s defence, the language itself doesn't mandate any protections here (the famous 'undefined behaviour'), but there's no reason your compiler can't add automatic runtime checking against illegal use of null. GCC supports it with "-fsanitize=null" [0]
It's much more than just null pointer dereferencing. Time and time again, it's been proven that Rust protects even very experienced C++ programmers from bugs they didn't realize they're even making.
This is a good point. Personal assurances count for little. No-one is above writing buggy code. Even C/C++ codebases written by very expert programmers, often have pointer-based bugs, especially if large and complex. Operating systems and drivers, for instance.
As well as having free-form pointers, C/C++ also have many, many dark corners.
What proportion of C++ programmers know that comparison = (c == c++); causes undefined behaviour?
It's awesome that Google did that. This is the first I've heard of it. But:
> The thing is that the overhead for this process really only makes sense at Google scale.
The software industry is far larger than Google. If we want to claim that software is a discipline of engineering, we all need to have access to that kind of reference data, rather than trying to feel our way around in the dark in comment threads about blog posts about somebody's personal experiences.
I won't go so far as to say there's no such thing as software engineering -- a number of people working for companies with large budgets have well earned that title, I'm sure -- but the extent to which the term is traded like currency in our industry is disrespectful to the discipline.
> So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time.
The fetishization of developer time is one of the problems slowing the maturation of our industry. It ignores end-user time, it ignores management time; it often focuses solely on the initial development time of a project and ignores entirely the ongoing maintenance time for a project.
How many codebases are there out there that are gigantic balls of mud? How much developer time has been wasted on trying to maintain or refactor those codebases? How many really dumb security issues have negatively impacted companies or end users? How many comments has tptacek left on one little forum in one musty corner of the internet over the years trying to explain cryptographic and security-related best practices to an infinite legion of under-trained developers?
How many people have lost their lives to software defects? Not even the really tricky CS stuff, I mean the kind of defects that any other engineering discipline uses as case studies in their introductory courses.
Which case study would you choose for our Galloping Gertie?
Certainly software has done an incalculable amount of good in the world, and its impact is far and away net positive.
But while software has been busy "eating the world", it has rarely paused to also consider the cost and damage it has wrought and whether there are practices that could be standardized to reduce those negative effects. So I disagree wholeheartedly that we're not yet at the point that these things are important. Depending on who you ask, computer programming is between 60 and 180 years old. That's well long enough for us to begin asking questions like, "what data do we have to support this approach or that approach?"
There is still plenty of room for experimentation and research. There is still plenty of room for hobbyists and tinkerers. This isn't an exclusive-or thing.
As much as I really do appreciate blog posts like this one, and the discussion they tend to generate, and especially that there's a new one to read every single day (he said, wryly), I can't help but see every one of them as another indicator of the immaturity of our profession.
I’d argue that the multiplicity of different programming languages and programming language paradigms suggests there likely isn't a teleological trajectory towards some single standard for programming.
Part of this is because many systems are evolving, because business needs have human inputs and are not always "logical." At the edges where this human interaction happens, we expand the domain of programming to that of human psychology. There definitely are empirical claims we can make human-computer interfaces, but it begins to get a bit messy.
To be clear, I am personally interested in becoming more rigorous about empirically justifying claims I make about the code I write. But I’m also interested in code because many of the problems it attempts to solve map the very complexity of the real world. In many ways, abstraction is a properly philosophical exercise, and I think it’s impossible to separate a pure engineering discipline from this broader context.
Programming is multi-disciplinary, and I think that’s a strength.
Physical constraints are more restrictive than information constraints. Physical constraints keep physical engineering from fragmenting into thousands of different but similar frameworks because the physical constraints rarely allow more than a few solutions to be competitive as best solutions. In information, the bounds/constraints are something more of a constructed popularity contest who the largest players are (Google, Amazon, Microsoft, Facebook, Apple, etc.) which carries as much or more weight than rigorously empirical comparisons.
I’d argue that the multiplicity of different programming languages and programming language paradigms suggests there likely isn't a teleological trajectory towards some single standard for programming.
We also have a multiplicity of building materials, tools, fabrication processes, etc. What's the standard way to make a steel object? Do you cast, forge, stamp, mill, sinter, roll, weld? I would expect engineering as a discipline to have more solid arguments for choosing which (combination) of those processes to use for a particular task than what is typically thrown around in discussions about choosing a programming language or paradigm.
>The fetishization of developer time is one of the problems slowing the maturation of our industry. It ignores end-user time, it ignores management time; it often focuses solely on the initial development time of a project and ignores entirely the ongoing maintenance time for a project.
The problem is that in many projects, especially small web-dev or simple automation projects, you simply don't know if they're going to be profitable. The margins are huge, since the upfront development cost is almost constant, you might lose $50,000, or you might make $500,000, or anything in-between, but you just don't really know beforehand. So obviously in this situation you want to become at least somewhat profitable as fast as possible, and then think about "doing things right" later. Is this horrible practice? Sure. But it's also the most logical thing to do here, because "doing things right" at the start is simply a huge risk that only pays off if you're successful anyway. And people would rather minimize losses than maximize gains.
On the other hand more traditional engineering tasks tend to require big up-front investments anyway, and "failing is not an option". I mean it really kind of isn't, if you need more money and/or more time you'll get that much more often here because the initial investment was so big already. So doing things right from the start makes complete sense.
1 engineer-hour =
W ms/search of latency
X GB-year of RAM
Y CPU-years of processing time
Z TB-year of hard disk space
etc.
The actual numbers are very confidential, I've forgotten them, and they're probably different from when I was there. Basically, everything is computed in dollar terms and normalized to engineer time. You assume your code will live for a certain lifetime (a year seemed reasonable when I was there), and you know how many queries your service currently gets (that's another number-you-should-know: usage data for the product you're working on). Multiply out the CPU usage increase by number of queries to get total CPU increase (you need this for capacity planning anyway), and you can compare that to the number of engineer-hours spent working on it to get cost effectiveness.
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.
> 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.
No industry can, unless it's something that has been done repeatedly before. If you ask a frontend designer specializing in WordPress to make a theme for WordPress and implement it, they can estimate it accurately.
What is thoroughly missing from this debate is the age old project management terms of scope and risks. As soon as you enter unknown land, the risk goes up. And risk means uncertainty and probably expenses. And if the people writing the checks change the scope, the original estimates goes out the window. If you're making a building, it's easier to understand that you cannot just change the scope after the blueprint is made. You have to get an architect to remake it, and everything done and ordered so far may or may not be salvageable. It happens in all industries, but just more so in software development.
I think OP's point, or at least my agreement, is how many often pretend the software industry is like other engineering industries and make such implications in their job titles.
There is still a lot of creative art and the more we stop pretending this isn't the case, the more people will be reasonable. There is still an high degree of technicality in the profession, but that doesn't mean its "engineering" -- you can be technical, not an engineer, and still respectable (heck, look at science in general). It's still a complex skill and makes lots of money for many businesses.
>they do not change so robustly & fast in short peroids of time.
Not really, rapid prototyping - especially due to 3d printing - is a thing now - you can iterate on a model as fast as you can in CS/CE.
Also - a lot of engineering disciplines use simulations - civil engineering, avionics etc - so they too can iterate quickly.
We are absolutely horrible at estimating. I had article somewhere that analyzed plenty of CS/CE projects and found that we are good at estimating median, and if something goes wrong in most complex part - the time to delivery can skyrocket 100x.
I think a more eloquent way is to say fundamentally creating long lasting software structures is more of an art rather than a science, and you can't just tell someone "go practice these 5 things and you'll be the next Picasso" you just have to do it a lot of times, over and over, learning from your mistakes.
There are no shortcuts. You have to build a ton of software, and make a lot of mistakes, and most importantly, learn from them. Then there's the other half of the equation and some people just have the creative mind to imagine the right framework, or tool or library or abstraction or architecture for the problem at hand.
The important thing is: Picasso knew what to study. Over time art had established a canon of things which helped people to get better at classical arts. Only after he studied that canon in depth and for a long time he could then break into new territories and start breaking rules intentionally to develop his own style/school.
Our craft is very bad at providing such a canon. It is even anti-intellectual in parts ("what do you mean you cannot be a master after x weeks? You are a gatekeeper! you suck").
That and we are still not sure what is important and what isn't (i.e. what should be part of the canon). Our medium of study changes all the time. Arts medium of study is reality and reality, for all our advances, doesn't really change.
We absolutely have a canon. You show me someone who has studied Dikjstra, Turing, Hoare, who has taken the time to pour over the Art of Computer Programming and Structures and Interpretations of Computer Programs, and poured over Ivan Sutherland, is familiar with the early days of IBM, Fairchild, Xerox PARC, and hundreds of other classics we consider to be "canon" that I am surely missing (just shooting from the hip here), and you'' be showing me, more likely than not, a damn good programmer. We have a canon, we just don't have the same studios, detail-oriented attention spans we once had, and the technology we have built is partly to blame.
Maybe related, you were once considered an ignorant brut in this country and others if you haven't read a library of literary classics, now we have kids growing up who barely know Shakespeare, or the rich body of the writing of the abolitionists or slave narratives (how many people you think in this country that even know 1/100th of what Henry Louis Gates Jr knows?) Do you think W.E.B Du Bois and Booker T Washington are common names anymore? I remember when everyone had the preamble of the Constitution and the Gettysburg Address burned into their minds, now we can't be expected to remember questions for a simple AWS Certification Exam, it's pathetic.
I think it is worth considering whether you may have the arrow of causality backwards. For tech specifically; your second paragraph is right on point. The folks I know who've got a fundamental grounding in the stuff you listed (and I count myself among them) all seemed to have an understanding of What Makes Systems Good before doing so. In many ways it becomes the naming of parts along with elaboration upon fairly basic ideas.
I do not believe in the idea of a bimodal distribution of software development (not just programming) aptitude, but I sometimes wonder.
(Regardless, I don't call myself an engineer. Engineers get sued if their stuff doesn't work. I'm a software developer, no matter how good and careful I might be.)
The "opinions" part is true, and has implications on whoever is paying for the software and whoever is maintaining it (with their own opinions, of course).
A company/client will often make decisions based on "opinions" too. "We need a website, what should we use to make it?" It's a bit of a blank canvas situation at first where a developer/engineer could come in and say "We should do it X way with Y libraries because <some opinion on why it's the best stack>". Devs could have totally different takes on the same canvas by a matter of opinion.
If I were to ask people "What type of car should I buy?", I would likely get a whole variety of answers from hybrids to SUVs to European and Japanese cars based on who I asked and what their own preferences and tendencies are. I may end up happy or I may end up unhappy depending on which opinion I'm swayed by and how much rigor I put into investigating the different opinions.
Software can be very similar when people providing the "opinions" are caught up in looking to use specific tools over trying to figure out an appropriate solution. When developers/engineers/designers/managers immediate choose tools as a blanket solution over understanding the scope and use-case for context, it's a sign to heavily question the authority of their opinions.
Software is an interesting animal because what PHP and NodeJS have in common is they were created as hobbies, as were a lot of the frameworks and software tech the world relies on. Maybe there is a bit of us software engineers liking the shiny new thing?
There are a lot of dynamics going on. One is programmer's curiosity but then there is a financial incentive to be on the latest tech. If you see React jobs paying more than Angular jobs, it might be a sign to jump ship which has nothing to do with technical merits. Then there is things like Blockchain that excites investors and techies alike, even when it's a useless solution for something.
People sitting in a room deciding the genuine best thing to do is going to be hard with all these dynamics going on.
We can't even accurately estimate the cost of a complex project given our choice of tools
We've been building bridges for thousands of years, and still the relatively simple bridge they built down the road from me took 2.5 years to complete instead of the estimated 9-12 month.
I've seen non-science in Healthcare, and I've spoke out against it. I don't really understand why people are stubborn when there is data, and the data is solid.
If I could wish anything in software engineering- follow the data.
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."
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.
It's definitely not about the environment. Yes, there are browser inconsistencies, but for the most part, this is not a major issue today. The problem of js apps is handling asynchronicity, having to fetch data from the server and managing UI state and in the case of an SPA, having to take care of routing, permissions, timeouts, errors etc. When you sum it all up, you end up with a front-end that mostly needs to replicate all logic from the server, apart from running the sql queries.
On the other side, when you render on the server, everything is already there. It's easy to write logic when the data you need is an sql query away and all you need to do is spit out some html. What gets a bit complex is keeping working state between pages and this usually requires handling sessions, cookies etc.
Well, the environment isn't the only factor, but it's the biggest one. You have to take care of routing, permissions, timeouts, errors etc on the server as well. Data being "an sql query away" on the server is similar to being "an AJAX call away" on the client.
If you have a UI, you're going to have to manage UI state somewhere. Even if you have no client-side code, you've marshal that state into strings to send to the client, and then parse it all out again on the server when you get the next request. Remember hidden form fields? Heck, this very site has some pretty interesting history about attempts to solve that problem elegantly. It was a PITA.
Ultimately, none of that has to do with Javascript; it's inherent in a client-server architecture. The one thing that is specific to JS is asynchronicity. If you don't like that, ok, fair enough, but that's a matter of taste. It has advantages as well as disadvantages, and with Promises and async/await, it's actually pretty elegant. It's certainly not the case that asynchronicity makes you write shit code.
Your first paragraph is exactly my point. Because in an SPA, you have to handle it in both places, not only on the server. That makes it twice as hard as an old fashioned server-side mvc page.
> Data being "an sql query away" on the server is similar to being "an AJAX call away" on the client.
This is a bit disingenuous, since sql calls in most back end languages are synchronous. Also an ajax call needs to update the UI to tell the user something is happening. This might mean disabling controls, showing spinners etc.
All of this goes away if you only use server-side rendering since form requests are natively handled by the browser.
> It's certainly not the case that asynchronicity makes you write shit code.
But it expands the number of cases you have to deal in the UI, to show all the loading states, error states etc.
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).
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.
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.
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.
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?
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.
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.
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).
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.
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.
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.
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.
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.
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.
All the state management stuff seems to be tied up in (=synonymous with) attempts to purify JS frameworks and codebases, as in "purely functional". It's... kinda silly and far removed from either the problem at hand, or the strengths of Javascript (such as they are) much of the time.
Meanwhile objects representing various parts of the view, and plenty of models that don't look much like "modern" JS state management, remain the norm elsewhere, and the sky is not falling. I do not know what to make of it. I go along with it when in that sort of company—when in Rome, and all that—but the evangelism can be pretty funny.
Anyway a bunch of the stuff isn't half as special as you'd think reading about it through the usual channels. Redux? A data cache and a so-so local event bus with somewhat awkward semantics and a few really bad terminology choices thrown in. Whee. There's your "state management". Not that it's useless, but you'd swear it's black magic reading all the blog posts about it.
The main benefit of purely functional systems is function composition. The ability to build entire programs through the composition of function primitives. Composition without dependencies.
The problem with javascript is that this concept is entirely lost on react developers. Due to the untyped nature of javascript and it's close linkage with html. HTML is made up of dependent components and this essentially puts dependency injection into javascript leading to JAVA like issues that the functional paradigm was suppose to solve.
> I never really understood why Javascript developers wanted a library to help them manage state
The reason is rooted in how browsers work.
In native software you can "just" render your data structures directly to the screen. In the browser, barring webgl, you can't render your data structures directly to the screen, instead, you're forced to interact with an imperative browser API to individually manage bespoke UI widgets that store their own state internally and can't understand nor access any of the data structures defined for your business logic. The only option left is to manually update the internal state of the browser UI widgets whenever you update the internal state of your application. Manually keeping the two states in snyc is a real pain, highly bug prone, and a maintenance nightmare. The front-end browser frameworks came along as a way to "auto-sync" the business logic state with the browser ui state.
That's the same way you work with literally every other UI framework (except the immediate-mode GUIs popular in gamedev), complete with the built-in event loop that's hidden from you. Web isn't special here, except that no other framework I've seen allows you to modify the UI by programmatically editing the serialized text description of it.
> Again I don't understand this argument. What's difficult about it? People have been doing it with win forms for well over a decade now.
And yet it's recognized as a problem there, too, and one of the more recent solutions is state management libraries inspired by those used in Web apps, e.g., there are fairly direct copies/adaptations of React and Redux for .NET specifically to address this issue.
I think jQuery got a bad rap because so many script kiddies would drop the entire damn framework into a page when they just didn't feel like writing a standard selector to do a mobile menu.
I mean, if all you're doing is showing and hiding a mobile menu, you can do that in a really expanded form in like 5 lines of vanilla JS, and not have your user download 90 KB* of crap.
*And you BETTER be using the minified version for production.
90 KB is probably bad for a marketing page, but it’s nothing for a B2B or internal use app, particularly when the second use is just the “you already have it” HTTP header response.
I don't disagree, but when so many public websites are unloading megabytes of Javascript for simple tasks, it feels like that attitude is the core problem. I'm not opposed to using frameworks when they're needed, I just have a problem with people using them to shorten up already short and very easy code because they can't be bothered to Google for a few minutes.
I'm not being hostile, I apologize if you took it that way. I'm just making a point about how so many dev's claim to have the right answer until you need to rely on them to get something done. Projects turn to a mess mostly due to things one single person cannot control. I don't know a single person, including myself, who've thought that their code didn't look like shit 6 months to a year down the road. I think we always get better and we'll always criticize what we don't know and understand. This includes mountains of other peoples code (garbage or not).
He did just apologize in case that person perceived something hostile when it was not meant to be hostile. He should not have apologized it seems. Damned if you do, damned if you do not.
The problem is, even if you try to contribute negative LOC, every other week your boss/customer/PM sees a new feature in their dreams or hears about a new technology at a conference and demands you put it in there right now.
Every system that I've built so far has started out with a simple, obvious set of rules (both new systems and replacements for old systems). Then the customer/PM/whatever notices just one more edge case. And another. And another. And another. The truth is that reality is frustratingly complicated. Especially if the reality you're mapping contains the internal bureaucracies of large companies.
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.
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.
Deleting code is not always better. I know a lot of developers who like to "refactor" code by making everything more terse and they regard that as a win even though the code is now cleverly incomprehensible.
I agree, it depends of the code, and if you need to replace it: by what.
I'm actually more found of when I don't even have to replace it: just delete the damn obsolete shit. Not replace. Delete. Most of the time it for cases where it is just dead. Sometimes it is only quasi-dead (from an incomplete previous modification) and in a few cases deleting it actually fixes some bugs.
Having bad software or a bad website is very often not an existential threat to companies, but having no software or no website is very often an existential threat.
The secret is, you don't have to not write and/or delete everything indiscriminately.
The second thing is: companies do not only try to avoid existential threats; they also attempt to have economical approaches. If anything needs to be maintained, there is the potential, if it is crappy, to make maintenance costly.
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.
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.
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.
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?
I've gone in the opposite direction in my career.
Overbuilding the initial version of something for a bunch of anticipated (rather than actual use/failure scenarios) is something I now work very hard to avoid.
The key IMHO is really being nimble enough to extract and/or refactor and/or refine as soon as it is needed. Not before, not after.
"Overly robust" code is actually a huge problem sometimes. All that unused code is in there, giving the appearance of being robust, but is not actually battle-tested....
" 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.
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.
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.
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?
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?
I remember seeing this one post on HN from some PHP consultancy that had open sourced some kind of PHP web app that was "engineered from the start to be secure".
I took a look at the code on GitHub and it was absolutely horrible. They basically built their own mini-framework, poorly, with mixed concerns and poor, ad-hoc and inconsistent validation everywhere. Terrible.
I left an issue on GitHub with my findings and got into an argument with the author in the HN submission about how it's disingenous to say something is engineered from the ground up to be secure, if you're eschewing all the man hours that have gone into something like Larvel. I think his reasoning boiled down to "Larvel has CVE's so it's not secure".
> This is not engineering a project to be "simply secure", in the sense that it is definitely not simple and probably not secure!
Messy, duplicated code that re-invents the wheel hides security bugs.
Saying "Windows has security issues, so I'm going to write my own operating system for my software" doesn't mean you can't knock it out of the park and make the most secure operating system ever... but I wouldn't exactly bet on that being the case.
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.
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?
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.
I think the main problem with the current Javascript UI frameworks is that they introduce an 'abstract middleman'that distances developers from what is actually happening in the browser. I expect there are many web developers unfamiliar enough with MVC that they are drawn to the Javascript frameworks even though MVC isn't a particularly difficult concept.
But there are tons of laravel sites, so there is a substantial profit motive to look for vulnerabilities in them.
It's like, outdated Wordpress sites get hacked all the time, but if I just threw together my own shitty blog in PHP and MySQL there's almost no chance it would, as no one (generally) is going to take the time to figure out hacks for just one site (especially for SMB).
> 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.
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.
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.
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.
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.
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.
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.
Easy if you don't have to have it pixel perfect for them. Just build it out with CSS Grid and the CSS variables, then look at the broken mess on IE and make it work. Who cares if things are not centered on IE11. It is not an HTML5 browser and is only there for legacy support - ActiveX and all that.
Also add a banner at the top telling people they need to use their other browser for the page.
What business are you in where 8% are still on IE11?
COBOL springs to mind. It sounds like you have a profitable niche supporting legacy stuff. Edge came out five years ago and IE11 was depreciated.
You can try the polyfill approach. This is generally not recommended as it wastes bandwidth. But since your customers have bandwidth you could go with polyfills. Or just stay stuck in the past with a niche of writing IE11 compatible stuff. That could be career limiting, IE11 is getting as irrelevant as 8.3 FAT filenames.
Edge is supposedly an option even back to Windows 7, though I don't believe it's a required security update. I haven't used a Windows 7 system in long enough that I'm not sure.
At this point it is reasonable to tell people they NEED to install a more modern (and more security up to date!) web browser, be it Google Chrome, Microsoft Edge, or Mozilla Firefox.
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.
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.
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.
> It replaced a site that was pretty much a home-grown PHP framework written by a single developer. Random mixed logic in templates, hard to update CSS and a poorly designed 'not-an-ORM' ORM.
Not to say that your rewrite is like that, but one man's garbage is another man's treasure.