If anyone wants to write boring tech full time (PHP 5, CSS 2, HTML 4, and regular JavaScript), let me know. I’m hiring!
Php 5 would not be boring and safe. You'd have some interesting challenges writing in an unsupported language version
How boring should your team's codebases be
121–130 of 235 posts
Re: How boring should your team's codebases be
#122Earlier quoted context omitted.
Well if it was only 100 lines of plain JS then how would one guard against reflection attacks? I.e. submitting HTML (like script tags) then getting that to render when others view the tainted data.
Because on this way of building sites, the user submitted data is escaped before it reaches the browser. E.g.: https://go.dev/play/p/MmNSxU5QfAb (hit run to see the output). The JS wouldn't need to do any escaping, because it's not trusted to handle any unescaped data. It's operating on the already-escaped html template.
They certainly weren't using Go, or as stated, any framework. Also no mention of any type of web server; not sure what magical code was creating dynamic HTML from the database. Where was the business logic? Stored Procedures? No mention of more dynamic functions... No integrations... Sure sounds like a desktop browser-only app while the majority of the world today wants some mobile functions from almost every system.
There is a lot information, which is understandable but also conveniently supports a very unflattering narrative while simultaneously promoting the OP's awesomeness.
Re: How boring should your team's codebases be
#123If anyone wants to write boring tech full time (PHP 5, CSS 2, HTML 4, and regular JavaScript), let me know. I’m hiring!
Php 5 would not be boring and safe. You'd have some interesting challenges writing in an unsupported language version
There are no challenges. The code I wrote in 2000 still works in 2020 and will work in 2030. That’s why it’s boring tech - it just works without thinking or deleting node_modules directory every day.
Re: How boring should your team's codebases be
#124Earlier quoted context omitted.
>> deployed to over 2000 locations Were there 2000 independent systems / SQL server instances running or just one? 2K separate deployments to manage (with 1K users each), does sound a little scary. Of course, perhaps that is not what is going on at all.
Which is actually kinda funny, because some of the "complex" technology the OP is railing against allows us today to manage thousands of databases both easily and efficiently... IF the systems are built with a more current approach. This is why I try to understand ALL of the motivations for disruptive change and not immediately assume incompetence and self-interest bordering on criminal.
Sometimes complexity is conflated with lack of familiarity. Instead of using the term "complexity", we should state what the actual problem is.
Re: How boring should your team's codebases be
#125Earlier quoted context omitted.
Because on this way of building sites, the user submitted data is escaped before it reaches the browser. E.g.: https://go.dev/play/p/MmNSxU5QfAb (hit run to see the output). The JS wouldn't need to do any escaping, because it's not trusted to handle any unescaped data. It's operating on the already-escaped html template.
They certainly weren't using Go, or as stated, any framework. Also no mention of any type of web server; not sure what magical code was creating dynamic HTML from the database. Where was the business logic? Stored Procedures? No mention of more dynamic functions... No integrations... Sure sounds like a desktop browser-only app while the majority of the world today wants some mobile functions from almost every system.…
I think you're reading them far too strictly. I don't think they literally meant they were using nothing beyond JUST the SQL Server and then somehow getting HTML out of that, with 100 lines of JS on top. Unless I misread, I don't see anything that implies they weren't using something like PHP or ASP, for example.
Re: How boring should your team's codebases be
#126There's never a simple answer to this. Here's some of the things we encounter: * A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them. * Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what…
> A bored developer is an unhappy developer A boring codebase doesn't make a bored developer, on the contrary it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that. > Your good developers are…
I agree 100% with your first comment. The best developers care about the impact their work has above all else. Sure, they might prefer Ruby, or Golang, or whatever, but at the end of the day the results are what they are after.
However, somehow we’ve created a world where the tools and techniques matter more than the output. I have no idea why this is, but I see it every day where engineers want to refactor code and try every new trick or tool they can.
Keeping track of what is going on is generally good. Trying to apply every hot new thing to a production codebase is a recipe for disaster!
Re: How boring should your team's codebases be
#127It feels like there is an article like this every other week. They reflect the same generic view which is broadly true yet I think is not very useful as an advice. In a highly creative field like software competitive advantage often outweighs comparative disadvantage. In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete co…
This is a very good point. There are definitely "risky novel" choices that could make your company a success. But I've also seen many teams drowning in a soup of random tech choices. I'd love to be able to write some more specific advice on this topic but mostly I just want people to be mindful of the impacts of their choices and actively choose risk rather than having it sneak up on them.
My first time as a team lead I saw value in little side experiments on non-core parts. Now I think that's only OK if there is time and budget to roll them back if they prove to be a bad fit. Otherwise they accrete and become a drag on velocity.
Re: How boring should your team's codebases be
#128I have come to learned that there’s no answer to this “problem”.
Even if you stick with tried and true framework, eventually that framework aged, and then developers start complaining that the framework is arcane. For example, how many HN readers here know WebObjects?
But the flip side is equally problematic. How many times do we have to change frontend frameworks? Just to render some divs on a web application?
Somewhere in the middle seemed to be the right answer. Just build the web application with new-ish technology like Go or Rust or Elixir, and then sprinkle some JS like HTMX for interactivity.
Re: How boring should your team's codebases be
#129Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any s…
Yea government work is full of that.
Kickbacks galore, my brother works in ed-tech. He said one state rewrites their public school report card system every two years like clockwork because of that.
Re: How boring should your team's codebases be
#130Earlier quoted context omitted.
Php 5 would not be boring and safe. You'd have some interesting challenges writing in an unsupported language version
There are no challenges. The code I wrote in 2000 still works in 2020 and will work in 2030. That’s why it’s boring tech - it just works without thinking or deleting node_modules directory every day.
The excitement comes when security issues are discovered in no longer maintained code