5 ms·

Back in the late 80s and early 90s there was a craze called CASE - Computer-Aided Software Engineering. The idea was humans really suck at writing code, but we'

Back in the late 80s and early 90s there was a craze called CASE - Computer-Aided Software Engineering. The idea was humans really suck at writing code, but we're really good at modeling and creating specifications. Tools like Rational Rose arose during this era, as did Booch notation which eventually became part of UML. The problem was it never worked. When generating the code, the best the tools could do was create all the classes for you and maybe define the methods for the class. The tools could not provide an implementation unless it provided the means to manage the implementation within the tool itself - which was awful. Why have you likely not heard of any of this? Because the fad died out in the early 2000's. The juice simple wasn't worth the squeeze. Fast-forward 20 years and I'm working in a new organization where we're using ArchiMate extensively and are starting to use more and more UML. Just this past weekend I started wondering given the state of business modeling, system architecture modeling, and software modeling, could an LLM (or some other AI tool) take those models and produce code like we could never dream of back in the 80s, 90s, and early 00s? Could we use AI to help create the models from which we'd generate the code? At the end of the day, I see software architects and software engineers still being engaged, but in a different way than they are today. I suppose to answer your question, if I wanted to future-proof my career I'd learn modeling languages and start "moving to the left" as they say. I see being a code slinger as being less and less valuable over the coming years. Bottom line, you don't see too many assembly language developers anymore. We largely abandoned that back in the 80s and let the computer produce the actual code that runs. I see us doing the same thing again but at a higher and more abstract level.

neilv 2y ago
I worked on CASE, and generally agree with this. I think it's important to note that there were a couple distinct markets for CASE: 1. Military/aerospace/datacomm/medical type technical development. Where you were building very complex things, that integrated into larger systems, that had to work, with teams, and you used higher-level formalisms when appropriate. 2. "MIS" (Management Information Systems) in-house/intranet business applications. Modeling business processes and flows, and a whole lot of data entry forms, queries, and printed reports. (Much of the coding parts already had decades of work on automating them, such as with WYSIWYG form painters and report languages.) Today, most Web CRUD and mobile apps are the descendant of #2, albeit with branches for in-house vs. polished graphic design consumer appeal. My teams had some successes with #1 technical software, but UML under IBM seemed to head towards #2 enterprise development. I don't have much visibility into where it went from there. I did find a few years ago (as a bit of a methodology expert familiar with the influences that went into UML, as well as familiar with those metamodels as a CASE developer) that the UML specs were scary and huge, and mostly full of stuff I didn't want. So I did the business process modeling for a customer logistics integration using a very small subset, with very high value. (Maybe it's a little like knowing hypertext, and then being teleported 20 years into the future, where the hypertext technology has been taken over by evil advertising brochures and surveillance capitalism, so you have to work to dig out the 1% hypertext bits that you can see are there.) Post-ZIRP, if more people start caring about complex systems that really have to work (and fewer people care about lots of hiring and churning code to make it look like they have "growth"), people will rediscover some of the better modeling methods, and be, like, whoa, this ancient DeMarco-Yourdon thing is most of what we need to get this process straight in a way everyone can understand, or this Harel thing makes our crazy event loop with concurrent activities tractable to implement correctly without a QA nightmare, or this Rumbaugh/Booch/etc. thing really helps us understand this nontrivial schema, and keep it documented as a visual for bringing people onboard and evolving it sanely, and this Jacobson thing helps us integrate that with some of the better parts of our evolving Agile process.
- taylodl 2y ago
  As I recall, the biggest problem from the last go-around was the models and implementation were two different sets of artifacts and therefore were guaranteed to diverge. If we move to a modern incarnation where the AI is generating the implementation from the models and humans are no longer doing that task, then it may work as the models will now be the only existing set of artifacts. But I was definitely in camp #2 - the in-house business applications. I'd love to hear the experiences from those in camp #1. To your point, once IBM got involved it all went south. There was a place I was working for in the early 90s that really turned me off against anything "enterprise" from IBM. I had yet to learn that would apply to pretty much every vendor! :)
  - neilv 2y ago
    FWIW, CASE developers knew pretty early on that the separate artifacts diverging was a problem, or even the problem, and a lot of work was on trying to solve exactly that. Approaches included having single source for any given semantics, and doing various kinds of syncing between the models. Personally, I went to grad school intending to finally "solve" this, but got more interested in combining AI and HCI for non-software-engineering problems. :)
indrora 2y ago
> Bottom line, you don't see too many assembly language developers anymore. And where you do, no LLM is going to replace them because they are working in the dark mines where no compiler has seen and the optimizations they are doing involve arcane lore about the mysteries of some Intel engineer's mind while one or both of them are on a drug fueled alcoholic deep dive.
- taylodl 2y ago
  Out of curiosity, who does assembly language programming these days? Back in the 90s the compilers had learned all our best tricks. Now with multiple instruction pipelines and out-of-order instruction processing and registers to be managed, can humans still write better optimized assembly than a compiler? Is the juice worth that squeeze? I can see people still learning assembly in a pedagogical setting, but not in a production setting. I'd be interested to hear otherwise.
  - indrora 2y ago
    Assembly is still relatively popular in the spaces of very low level Operating System work, exploit engineering, and embedded systems where you need cycle-accurate timing.
  - gjadi 2y ago
    ffmepg is famous for using asm. For exemple : https://news.ycombinator.com/item?id=42041301 https://news.ycombinator.com/item?id=42041301
627467 2y ago
It's interesting you say this because in my current process to learn to build apps for myself I first try build mermaid diagrams aided by LLM. And when I'm happy, i then ask it to generate the code for me based on these diagrams. I'm no SWE and probably never will be. SWE probably don't consider what I do "building an app" but I don't really care
- aprilthird2021 2y ago
  Diagramming out what needs to be built is often what some of the highest paid programmers do all day
  - steve_adams_86 2y ago
    This is what keeps crossing my mind. Even trivial things like an ETL pipeline for processing some data at my work fall into this category. It seemed trivial on its surface, but when I spoke to everyone about what we were doing with it and why (and a huge amount of context regarding the past and future of the project), the reason the pipeline wasn’t working properly was both technically and contextually very complex. I worked with LLMs on solving the problems (I always do, I guess I need to “stay sharp”), and they utterly failed. I tried working from state machine definitions, diagrams, plain English, etc. They couldn’t pick up the nuances at all. Initially I thought I must be over complicating the pipeline, and there must be some way to step it back and approach it more thoughtfully. This utterly failed as well. LLMs tried to simplify it by pruning entire branches of critical logic, hallucinating bizarre solutions, or ignoring potential issues like race conditions, parallel access to locked resources, etc. entirely. It has been a bit of an eye opener. Try as I might, I can’t get LLMs to use streams to conditionally parse, group, transform, and then write data efficiently and safely in a concurrent and parallel manner. Had I done this with an LLM I think the result eventually could have worked, but the code would have been as bad as what we started with at best. Most of my time on this project was spent planning and not programming. Most of my time spent programming was spent goofing around with LLM slop. It was fun, regardless.
    - sleepybrett 2y ago
lubujackson 2y ago
This is more or less my take. I came in on Web 1.0 when "real" programmers were coding in C++ and I was mucking around with Perl and PHP. This just seems like just the next level of abstraction. I don't forsee a "traders all disappeared" situation like the top comment, because at the end of the day someone needs to know WHAT they want to build. So yes, less junior developers and development looking more like management/architecting. A lot more reliance on deeply knowledgable folks to debug the spaghetti hell. But also a lot more designers that are suddenly Very Successful Developers. A lot more product people that super-charge things. A lot more very fast startups run by some shmoes with unfundable but ultimately visionary ideas. At least, that's my best case scenario. Otherwise: SkyNet.
- Zababa 2y ago
  Here's to Yudkowsky's 84th law.

neilv 2y ago

I worked on CASE, and generally agree with this. I think it's important to note that there were a couple distinct markets for CASE: 1. Military/aerospace/datacomm/medical type technical development. Where you were building very complex things, that integrated into larger systems, that had to work, with teams, and you used higher-level formalisms when appropriate. 2. "MIS" (Management Information Systems) in-house/intranet business applications. Modeling business processes and flows, and a whole lot of data entry forms, queries, and printed reports. (Much of the coding parts already had decades of work on automating them, such as with WYSIWYG form painters and report languages.) Today, most Web CRUD and mobile apps are the descendant of #2, albeit with branches for in-house vs. polished graphic design consumer appeal. My teams had some successes with #1 technical software, but UML under IBM seemed to head towards #2 enterprise development. I don't have much visibility into where it went from there. I did find a few years ago (as a bit of a methodology expert familiar with the influences that went into UML, as well as familiar with those metamodels as a CASE developer) that the UML specs were scary and huge, and mostly full of stuff I didn't want. So I did the business process modeling for a customer logistics integration using a very small subset, with very high value. (Maybe it's a little like knowing hypertext, and then being teleported 20 years into the future, where the hypertext technology has been taken over by evil advertising brochures and surveillance capitalism, so you have to work to dig out the 1% hypertext bits that you can see are there.) Post-ZIRP, if more people start caring about complex systems that really have to work (and fewer people care about lots of hiring and churning code to make it look like they have "growth"), people will rediscover some of the better modeling methods, and be, like, whoa, this ancient DeMarco-Yourdon thing is most of what we need to get this process straight in a way everyone can understand, or this Harel thing makes our crazy event loop with concurrent activities tractable to implement correctly without a QA nightmare, or this Rumbaugh/Booch/etc. thing really helps us understand this nontrivial schema, and keep it documented as a visual for bringing people onboard and evolving it sanely, and this Jacobson thing helps us integrate that with some of the better parts of our evolving Agile process.

taylodl 2y ago
As I recall, the biggest problem from the last go-around was the models and implementation were two different sets of artifacts and therefore were guaranteed to diverge. If we move to a modern incarnation where the AI is generating the implementation from the models and humans are no longer doing that task, then it may work as the models will now be the only existing set of artifacts. But I was definitely in camp #2 - the in-house business applications. I'd love to hear the experiences from those in camp #1. To your point, once IBM got involved it all went south. There was a place I was working for in the early 90s that really turned me off against anything "enterprise" from IBM. I had yet to learn that would apply to pretty much every vendor! :)
- neilv 2y ago
  FWIW, CASE developers knew pretty early on that the separate artifacts diverging was a problem, or even the problem, and a lot of work was on trying to solve exactly that. Approaches included having single source for any given semantics, and doing various kinds of syncing between the models. Personally, I went to grad school intending to finally "solve" this, but got more interested in combining AI and HCI for non-software-engineering problems. :)

indrora 2y ago

> Bottom line, you don't see too many assembly language developers anymore. And where you do, no LLM is going to replace them because they are working in the dark mines where no compiler has seen and the optimizations they are doing involve arcane lore about the mysteries of some Intel engineer's mind while one or both of them are on a drug fueled alcoholic deep dive.

taylodl 2y ago
Out of curiosity, who does assembly language programming these days? Back in the 90s the compilers had learned all our best tricks. Now with multiple instruction pipelines and out-of-order instruction processing and registers to be managed, can humans still write better optimized assembly than a compiler? Is the juice worth that squeeze? I can see people still learning assembly in a pedagogical setting, but not in a production setting. I'd be interested to hear otherwise.
- indrora 2y ago
  Assembly is still relatively popular in the spaces of very low level Operating System work, exploit engineering, and embedded systems where you need cycle-accurate timing.
- gjadi 2y ago
  ffmepg is famous for using asm. For exemple : https://news.ycombinator.com/item?id=42041301 https://news.ycombinator.com/item?id=42041301

627467 2y ago

It's interesting you say this because in my current process to learn to build apps for myself I first try build mermaid diagrams aided by LLM. And when I'm happy, i then ask it to generate the code for me based on these diagrams. I'm no SWE and probably never will be. SWE probably don't consider what I do "building an app" but I don't really care

aprilthird2021 2y ago
Diagramming out what needs to be built is often what some of the highest paid programmers do all day
- steve_adams_86 2y ago
  This is what keeps crossing my mind. Even trivial things like an ETL pipeline for processing some data at my work fall into this category. It seemed trivial on its surface, but when I spoke to everyone about what we were doing with it and why (and a huge amount of context regarding the past and future of the project), the reason the pipeline wasn’t working properly was both technically and contextually very complex. I worked with LLMs on solving the problems (I always do, I guess I need to “stay sharp”), and they utterly failed. I tried working from state machine definitions, diagrams, plain English, etc. They couldn’t pick up the nuances at all. Initially I thought I must be over complicating the pipeline, and there must be some way to step it back and approach it more thoughtfully. This utterly failed as well. LLMs tried to simplify it by pruning entire branches of critical logic, hallucinating bizarre solutions, or ignoring potential issues like race conditions, parallel access to locked resources, etc. entirely. It has been a bit of an eye opener. Try as I might, I can’t get LLMs to use streams to conditionally parse, group, transform, and then write data efficiently and safely in a concurrent and parallel manner. Had I done this with an LLM I think the result eventually could have worked, but the code would have been as bad as what we started with at best. Most of my time on this project was spent planning and not programming. Most of my time spent programming was spent goofing around with LLM slop. It was fun, regardless.
  - sleepybrett 2y ago

lubujackson 2y ago

This is more or less my take. I came in on Web 1.0 when "real" programmers were coding in C++ and I was mucking around with Perl and PHP. This just seems like just the next level of abstraction. I don't forsee a "traders all disappeared" situation like the top comment, because at the end of the day someone needs to know WHAT they want to build. So yes, less junior developers and development looking more like management/architecting. A lot more reliance on deeply knowledgable folks to debug the spaghetti hell. But also a lot more designers that are suddenly Very Successful Developers. A lot more product people that super-charge things. A lot more very fast startups run by some shmoes with unfundable but ultimately visionary ideas. At least, that's my best case scenario. Otherwise: SkyNet.

Zababa 2y ago
Here's to Yudkowsky's 84th law.