131–140 of 235 posts
Perhaps a controversial take: it’s difficult to write boring code in the common boring languages because they are not powerful enough to express the problem domain without accidental complexity.
There'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. Unhappy developers leave. Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development? Why do people think they can "play with new technologies" at work, which i…
The same reason software developer salaries are so high. Supply and demand. Companies will do back flips to attract and keep software engineering talent.
> which is wasting not only company money
Some of the best cost saving solutions I've come up with in my career have been thanks to "playing" with new technology. It's the opposite of wasting company money.
> maybe it's time for software developers to grow up and start acting like adults in the workplace
There is nothing childish about loving your work, having fun while doing it, and bringing that attitude to work. It's infectious and great for company morale. Maybe it's time for the negative nancies to grow up, seek therapy, and start acting positive at work and having some fun.
Every 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…
> This is why we can't have simplicity: because it doesn't scale. No, it's because it doesn't sell.
Every 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…
It sounds like your project ended up working out well (ignoring the replacement). But one thing that would be hard for me when starting a project like this: How do you know that over time it won't grow into something terribly unmaintainable? You don't have an ORM, but then perhaps over time you re-implement most of the functionality of an ORM, and now new people need to learn that. Of course, you can start with out o…
Like pretty much all Angular projects?
Earlier quoted context omitted.
Is it open source or only available to clients?
I think I grossly oversold this thing because there's a lot of comments here asking for something. I don't really have this concept written down anywhere like a number of other ideas I have. But, I guess the short version is, if I had to make an elevator pitch or something: No framework is a configuration (maybe "distro" in the linux sense) of concepts (maybe "packages" in the software sense). A concept is either som…
Has this been tested against a more traditional architecture to solve a similar business problem? And if so what were its cons?
What frustrates me about the software industry is the many failed lineages problem. There are many mountains of code that get the job done at various companies but isn't shared. The lineage of these in-house frameworks or effective solutions to problems kind of don't go anywhere, they simply end. The lineage ends and doesn't cross pollenate. So lessons aren't shared. We are in an era of explosive growth where there i…
For mildly interesting code that you can realistically write yourself, there isn't a strict need to share code and cross polinate. Every little shop has a certain budget to try out new things, play around, and learn. If we come up with more or less the same things, that's fine. I'm much more fond of sharing ideas than sharing code. IMO developers' understanding is at least as important as the economics of crafting co…
My guess is you're correct, yet RAM stored DBs cannot guarantee persistence when things go wrong. Or at least they may introduce data loss if changes aren't fsync'd to durable storage or 2PC with replicas.
Every 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…
The solution might have good answers to all of those questions! It is perfectly possible to build a well-engineered system using those technologies!
But on almost every level the answers to those questions are going to be surprising.
Whereas the same thing built using webpack and a Ruby on Rails to Postgres backend will be much more legible.
‘Boring’ technology does not mean no technology.
Earlier quoted context omitted.
I understand the annoyance of it being replaced for a more complex more expensive system, but I would also like to know: What was the reasoning provided and what did decision makers truly believe about the whole thing?
> What was the reasoning provided Reasoning? Hah-ha. Haaaaa... It was an open government tender process, for which I, or the company I worked for was not eligible, despite the tender being "open". You see, a decade-long pedigree of actually having implemented the software used for this purpose did not qualify us for replacing it with a v2.0. There are rules , you see? They have to be followed! Or else. Or else bad th…
Earlier quoted context omitted.
Fantastically . The new one had "hand rolled cryptography", which should make you twitch uncontrollably if you know anything about security. The new application had, among other failings, hard-coded (unchangeable!) RSA keys used for communication channels. As in, all customers shared the same keys. I can't remember the exact specifics, but I swear at some point there was something like encrypted JSON in XML. Or was i…
> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. I can't be the only one here who is both skeptical and a little turned off by someone who says "You can stick any user input into a database query and you'll be fine", with a condesending pat on my head. Your comments continue to be incredibly one-sided and biased. The summary is "My work was p…
Like how Google has worked the past 2 decades? OP said snippets then you gloriously paraphrased it into a completely different statement.
There'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. Unhappy developers leave. Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development? Why do people think they can "play with new technologies" at work, which i…
Two reasons. 1) Because devs generally have other employment options. 2) Management has no idea how to judge what devs do.
1 is important, because devs can often go work somewhere that lets them work on fun technologies. This is usually at a smaller company and often comes with lower pay, but not so low that anyone would consider it suffering (still easily into the 6 figures).
2 means that the manager only sees the following option: Tell the dev they can't play with fun tech, risk them leaving, and spend many thousands of dollars on recruiting a replacement (who may also leave). OR Tell the dev they can play with the fun tech, and nothing immediately breaks (and the manager can go back to worrying about their day to day problems).
Taking the second option is not necessarily an irrational choice for the manager. Especially if that manager is using an "up or out" strategy (their plan is to be promoted or leave before the long term effects of these decisions can bite them).
Such is the realpolitik of the business world.