3 ms·

> Now a lot of programmers are designing and implementing the equivalent of high-rise buildings. I get your point, but I think it's a bit of a myth. I work on

by js8 3y ago

> Now a lot of programmers are designing and implementing the equivalent of high-rise buildings. I get your point, but I think it's a bit of a myth. I work on mainframe applications and when you look at the actual business logic, there is a comparable amount of it in the apps that are 20, 30, 40 years old. I would even say that the modern methods of building software are to the detriment because there is a lot of incidental complexity coming from the tooling. It seems that creation and maintenance of business logic for a given domain isn't really much helped with modern tooling, so it takes about the same time to develop. On the other hand, businesses today are demanding things to be done cheaper with more UX polish. This means that actual software capabilities (which require domain knowledge) are made less general and take more time to develop. I would say today, many applications are simpler in terms of features than 20 years ago.

lolinder 3y ago
If by "features" you mean "business logic", you might be right. But UX polish that makes the application accessible to ordinary people who are going to give the app 2-3 minutes to prove itself is a feature, and one that can take an overwhelming amount of engineering to get right. Dismissing that engineering because your mainframe applications do more "work" with less code is shortsighted, a continuation of the "frontend developers aren't real engineers" meme that has finally started to die.
- deleted 3y ago
  [deleted]
- daaaaomizez662 3y ago
  It's a feature if you are in the buisness of selling software to end users that need or want that, but that isn't the customer base of mainframe programmers or similar kinds of deep backend work. If all your customers care about is that the paperwork crunching and adding up the numbers gets done right and on time every day (and after that, as cheaply as possible) then it's actively counterproductive to spend resources on a nice frontend. I don't think anybody is implying that there is no market for frontend engineering, just that resources spent on frontend are necessarily resources not spent elsewhere, and that different teams naturally have different priorities.
- js8 3y ago
  I wasn't really dissing UX or frontends, that wasn't my intent. It's more about the approaches than validity of these fields. I'll illustrate what I mean by less features on desktop application. 30 years ago, there was a text editor called Ami Pro. You as a user were completely free to redefine its UI. You could also define keyboard shortcuts. Today, people use, say, Google Docs which doesn't have these features. Users are supposed to use common UX, designed by experts. But which one had better UX, really? I mean it's easy to say that medieval people built huts and now we build skyscrapers, and so the technology brought undeniable progress. But they also built cathedrals (note I am NOT using "cathedral" here in contrast with "bazaar"). Skyscraper building techniques don't really help you build cathedrals faster, because one of the attraction of the cathedral is that each of them is heavily customized and unique. The problem is, since it's easier to build skyscrapers with the same amount of material, nobody wants to build a cathedral anymore. And it's perhaps a loss. I was pointing out the cathedrals of software do exist, built with perhaps cruder tools, but more actual business logic and features. So in some strange way, having more productive tools to build applications also boxed our thinking into how things should be done, and I don't think it has to be that way. (Another perspective is that a medieval church used to be a sort of communal project more than a skyscraper is today. Commercial software used to be lot more moddable 20 or 40 years ago than it is today - MVS is a nice example. And out of these modding capabilities many features have been built - often by users - that would never make business sense today.)

by js8 3y ago

lolinder 3y ago

If by "features" you mean "business logic", you might be right. But UX polish that makes the application accessible to ordinary people who are going to give the app 2-3 minutes to prove itself is a feature, and one that can take an overwhelming amount of engineering to get right. Dismissing that engineering because your mainframe applications do more "work" with less code is shortsighted, a continuation of the "frontend developers aren't real engineers" meme that has finally started to die.

deleted 3y ago
[deleted]
daaaaomizez662 3y ago
It's a feature if you are in the buisness of selling software to end users that need or want that, but that isn't the customer base of mainframe programmers or similar kinds of deep backend work. If all your customers care about is that the paperwork crunching and adding up the numbers gets done right and on time every day (and after that, as cheaply as possible) then it's actively counterproductive to spend resources on a nice frontend. I don't think anybody is implying that there is no market for frontend engineering, just that resources spent on frontend are necessarily resources not spent elsewhere, and that different teams naturally have different priorities.
js8 3y ago
I wasn't really dissing UX or frontends, that wasn't my intent. It's more about the approaches than validity of these fields. I'll illustrate what I mean by less features on desktop application. 30 years ago, there was a text editor called Ami Pro. You as a user were completely free to redefine its UI. You could also define keyboard shortcuts. Today, people use, say, Google Docs which doesn't have these features. Users are supposed to use common UX, designed by experts. But which one had better UX, really? I mean it's easy to say that medieval people built huts and now we build skyscrapers, and so the technology brought undeniable progress. But they also built cathedrals (note I am NOT using "cathedral" here in contrast with "bazaar"). Skyscraper building techniques don't really help you build cathedrals faster, because one of the attraction of the cathedral is that each of them is heavily customized and unique. The problem is, since it's easier to build skyscrapers with the same amount of material, nobody wants to build a cathedral anymore. And it's perhaps a loss. I was pointing out the cathedrals of software do exist, built with perhaps cruder tools, but more actual business logic and features. So in some strange way, having more productive tools to build applications also boxed our thinking into how things should be done, and I don't think it has to be that way. (Another perspective is that a medieval church used to be a sort of communal project more than a skyscraper is today. Commercial software used to be lot more moddable 20 or 40 years ago than it is today - MVS is a nice example. And out of these modding capabilities many features have been built - often by users - that would never make business sense today.)