7 ms·

Something has gone very wrong in our industry. Typical in-house CRUD used to be relatively straightforward and a handful of developer/analyst hybrids could hand

by tabtab 8y ago

Something has gone very wrong in our industry. Typical in-house CRUD used to be relatively straightforward and a handful of developer/analyst hybrids could handle the vast majority of projects using tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer and has to be divided into specialists, including a front-end specialist. JavaScript gizmos are always "breaking" when new browser versions come out. It makes DLL-Hell of the 90's look good in comparison. Sure, the tools mentioned were more difficult to deploy to users, but we jacked up programming costs to gain deployability. We need better standards: HTML/JS/CSS/DOM is okay for some things, but one-size-fits-all has dragged down a lot of specialities, including in-house CRUD. Maybe we need one standard for "eye-candy" and games, and another for git-er-done GUI's. I had hoped "The Web" would mature and solve the bottlenecks, but it didn't. Are we really stuck with 5x the programming resources? Accountants, wake up and bop IT on the head.

holtalanm 8y ago
My experience seems to be a polar opposite of this.
- tabtab 8y ago
  A well-tuned web-stack can indeed lead to decent productivity. The problem is that the average shop either doesn't know how to tune the stack, or has no incentive to. A shop or domain settles on conventions, and one can potentially use these conventions to clean and tune a stack to fit an org like a glove. A handful of shops get it right. Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed. The thing is, the tools I mentioned didn't need frameworks; they were frameworks. This reduced the urge and ability for "local creativity" to run amok with fads and experiments. Fear of keeping-up-with-the-IT-Jones often creates chaos in my observation. Devs have to stick the latest and greatest into the stack to placate the fear of being obsoleted.
  - sibeliuss 8y ago
    > Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed Exactly! Without an engineer (or a team) to manage this then some serious problems can arise, including loss of productivity. If there _is_ someone managing this then productivity gains can be enormous.
    - tabtab 8y ago
      It's kind of like restaurants. The tools I mentioned are like franchises: you know what you are going to get ahead of time: a "B" to "B-" level of quality at "B" to "B-" prices. Individually-owned restaurants may be roach-motels, and/or have the Greatest Food You Ever Tasted. But it varies per owner and time.
claydavisss 8y ago
No different than any other part of the stack...everything that should be simple has become pointlessly complex. How many people here are evaluating Kubernetes for trivial services that could be easily addressed with twenty-year-old scaling models?
- markbnj 8y ago
  Do you have a particular example of something that should be simple but has become pointlessly complex? In my experience when people complain about complexity they are often complaining about a change from the thing they know to something they don't. On objective examination it can be the case that the old way wasn't simple either, because the complexity is inherent. Typically we move it around, put abstractions around it, but don't really change it fundamentally.
  - claydavisss 8y ago
    Probably 90% of projects that are using Kubernetes
  - tabtab 8y ago
    Re: when people complain about complexity they are often complaining about a change from the thing they know to something they don't. If something is truly better, then it should be easy to articulate why in a concrete manner, such as exploring total lines of code that need to be changed per a change request scenario that's realistic for your particular org (and not a cheesy textbook example). It's also good to see it actually working in similar organizations. Often people copy from dissimilar organizations and make a mess. Microservices are like this. They don't fit many shops or orgs; but because Netflix finds them useful, everybody has to copy. Often "new things" are passing fads. It's good to vet things for actual productivity improvement instead of just using buzzwords such as "separation of concerns". Otherwise, the org will have separation-of-wallet.
  - tracker1 8y ago
    One area of complexity I constantly rail against is dependency injection framworks or IoC... In most cases you can use what's built in, or don't need it. Layers of crap in "Enterprise" .net and java projects. If you actually have lots of complexity in the app, with lots of test coverage, or multiple target libraries, sure... but most don't have that. Aside from that, it really is resistance to change.
codingdave 8y ago
Typical in-house CRUD is now handled just by analysts, with no developers, using tools like Salesforce and Sharepoint. Well, to be fair, they get enhanced by developers... but the basic CRUD isn't an issue. Tying it to business workflows is. But the point is that LOB apps are not custom development anymore, and have not been for a long time.
- tabtab 8y ago
  Really simple applications, maybe. But SharePoint can't scale well in terms of features and cross-table-relations if and when the application needs to expand. It may save you up front, but bottle you in down the road. (I don't have enough experience with Salesforce to comment on it.)
root_axis 8y ago
> tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer a I've seen no evidence to support the suggestion that building CRUD apps for the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc. The web is very simple but extremely flexible and you can get as much or as little out of it as you like. If it takes 5x as long it means the technical management is inept. I also have personal experience with some huge internal VB and Delphi projects during the 90s that were utter nightmares, and I know anyone else working in that era can attest to similar experiences. > JavaScript gizmos are always "breaking" when new browser versions come out. It makes DLL-Hell of the 90's look good in comparison. This is just false. Standards compliant JS releases across the browsers have been extremely stable for years, there are no "JS gizmos" breaking because of browser releases. The DLL-Hell comparison is ridiculous, there is simply nothing even remotely comparable to that on the web today. > Maybe we need one standard for "eye-candy" and games, and another for git-er-done GUI's. This is an arbitrary distinction and not a technical one. The solution is to understand which problems need solving and then to select the appropriate tool (that you understand how to use) for the job.
- meredydd 8y ago
  > I've seen no evidence to support the suggestion that building CRUD apps for the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc Well, I have! We actually did the test, with Anvil (https://anvil.works https://anvil.works), which is explicitly a VB/Delphi-like platform for the web. We took a straightforward CRUD-y consulting project as a spec, and built it with traditional tools and with Anvil. We did our best to keep it fair: We raced an expert against an expert, and we kept the web tech simple: simple templating, minimal JS, etc. And it was still about 7 times faster with the Delphi-like tool. (It was actually 10x faster if you just count dev time, but we counted overhead meetings too - again, in an effort to be fair. It was still "one week" vs "one afternoon".)
  - tabtab 8y ago
    Similarly, many report that Dot-Net Web Forms development is usually quicker than MVC for in-house software (that doesn't need eye-candy) under normal circumstances[1], but developers don't want to use it because they are told it's "outdated" and it will rot their skill-set. [1] As suggested earlier, if the MVC stack is well-managed this may not be the case, but the average company has average management, by definition.

by tabtab 8y ago

holtalanm 8y ago

My experience seems to be a polar opposite of this.

tabtab 8y ago
A well-tuned web-stack can indeed lead to decent productivity. The problem is that the average shop either doesn't know how to tune the stack, or has no incentive to. A shop or domain settles on conventions, and one can potentially use these conventions to clean and tune a stack to fit an org like a glove. A handful of shops get it right. Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed. The thing is, the tools I mentioned didn't need frameworks; they were frameworks. This reduced the urge and ability for "local creativity" to run amok with fads and experiments. Fear of keeping-up-with-the-IT-Jones often creates chaos in my observation. Devs have to stick the latest and greatest into the stack to placate the fear of being obsoleted.
- sibeliuss 8y ago
  > Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed Exactly! Without an engineer (or a team) to manage this then some serious problems can arise, including loss of productivity. If there _is_ someone managing this then productivity gains can be enormous.
  - tabtab 8y ago
    It's kind of like restaurants. The tools I mentioned are like franchises: you know what you are going to get ahead of time: a "B" to "B-" level of quality at "B" to "B-" prices. Individually-owned restaurants may be roach-motels, and/or have the Greatest Food You Ever Tasted. But it varies per owner and time.

claydavisss 8y ago

No different than any other part of the stack...everything that should be simple has become pointlessly complex. How many people here are evaluating Kubernetes for trivial services that could be easily addressed with twenty-year-old scaling models?

markbnj 8y ago
Do you have a particular example of something that should be simple but has become pointlessly complex? In my experience when people complain about complexity they are often complaining about a change from the thing they know to something they don't. On objective examination it can be the case that the old way wasn't simple either, because the complexity is inherent. Typically we move it around, put abstractions around it, but don't really change it fundamentally.
- claydavisss 8y ago
  Probably 90% of projects that are using Kubernetes
- tabtab 8y ago
  Re: when people complain about complexity they are often complaining about a change from the thing they know to something they don't. If something is truly better, then it should be easy to articulate why in a concrete manner, such as exploring total lines of code that need to be changed per a change request scenario that's realistic for your particular org (and not a cheesy textbook example). It's also good to see it actually working in similar organizations. Often people copy from dissimilar organizations and make a mess. Microservices are like this. They don't fit many shops or orgs; but because Netflix finds them useful, everybody has to copy. Often "new things" are passing fads. It's good to vet things for actual productivity improvement instead of just using buzzwords such as "separation of concerns". Otherwise, the org will have separation-of-wallet.
- tracker1 8y ago
  One area of complexity I constantly rail against is dependency injection framworks or IoC... In most cases you can use what's built in, or don't need it. Layers of crap in "Enterprise" .net and java projects. If you actually have lots of complexity in the app, with lots of test coverage, or multiple target libraries, sure... but most don't have that. Aside from that, it really is resistance to change.

codingdave 8y ago

Typical in-house CRUD is now handled just by analysts, with no developers, using tools like Salesforce and Sharepoint. Well, to be fair, they get enhanced by developers... but the basic CRUD isn't an issue. Tying it to business workflows is. But the point is that LOB apps are not custom development anymore, and have not been for a long time.

tabtab 8y ago
Really simple applications, maybe. But SharePoint can't scale well in terms of features and cross-table-relations if and when the application needs to expand. It may save you up front, but bottle you in down the road. (I don't have enough experience with Salesforce to comment on it.)

root_axis 8y ago

> tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer a I've seen no evidence to support the suggestion that building CRUD apps for the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc. The web is very simple but extremely flexible and you can get as much or as little out of it as you like. If it takes 5x as long it means the technical management is inept. I also have personal experience with some huge internal VB and Delphi projects during the 90s that were utter nightmares, and I know anyone else working in that era can attest to similar experiences. > JavaScript gizmos are always "breaking" when new browser versions come out. It makes DLL-Hell of the 90's look good in comparison. This is just false. Standards compliant JS releases across the browsers have been extremely stable for years, there are no "JS gizmos" breaking because of browser releases. The DLL-Hell comparison is ridiculous, there is simply nothing even remotely comparable to that on the web today. > Maybe we need one standard for "eye-candy" and games, and another for git-er-done GUI's. This is an arbitrary distinction and not a technical one. The solution is to understand which problems need solving and then to select the appropriate tool (that you understand how to use) for the job.

meredydd 8y ago
> I've seen no evidence to support the suggestion that building CRUD apps for the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc Well, I have! We actually did the test, with Anvil (https://anvil.works https://anvil.works), which is explicitly a VB/Delphi-like platform for the web. We took a straightforward CRUD-y consulting project as a spec, and built it with traditional tools and with Anvil. We did our best to keep it fair: We raced an expert against an expert, and we kept the web tech simple: simple templating, minimal JS, etc. And it was still about 7 times faster with the Delphi-like tool. (It was actually 10x faster if you just count dev time, but we counted overhead meetings too - again, in an effort to be fair. It was still "one week" vs "one afternoon".)
- tabtab 8y ago
  Similarly, many report that Dot-Net Web Forms development is usually quicker than MVC for in-house software (that doesn't need eye-candy) under normal circumstances[1], but developers don't want to use it because they are told it's "outdated" and it will rot their skill-set. [1] As suggested earlier, if the MVC stack is well-managed this may not be the case, but the average company has average management, by definition.