Software Dev Can't Be Automated – It’s a Creative Process with an Unknown Goal
thehosk.medium.com
thehosk.medium.com
In fact, anyone who claims that any human activity has been automated faces a testing problem: how do you know? And a construct validity problem: how do you know that the new process is equivalent to the old in every way we care about?
Anything can be automated if you are allowed to ignore its true nature and make unchallenged claims.
even if narrowly, only within the sw dev domain?
AI and humans fail in different ways.
We don't understand AI failure, so it can cause collosal damage at the worst possible time
When a human makes a fatal mistake it bears the responsibility of that mistake and we have protocols to put in place to deal with that (including having somebody to blame and direct our anger against).
When a machine does a mistake it becomes much much unclear against whom direct our anger. The engineers who built it? The corporation that profited from it and could have invested more?
An AI doesn't have to be better than a focused human with lots of experience, great education, at peak health, with a good night of sleep and no distractions. It just has to be better than the average human to be useful, and that's a very, very different scenario.
actually by the condition of my predicate I can - I postulated a 'slight change in inputs that humans would consider inessential' if a human considers it essential it is not a change that is allowed into our reasoning here.
Now of course I said this because in the past, as noted by the article I linked in another response, AIs have failed because of changes in inputs that people discussing the matter thought inessential. So while the logic of my statement does not allow for humans considering the changes essential, the actual examples I was thinking of when I made my statement might very well have had changes that humans would consider essential.
So perhaps we should consider the actual rather than the theoretical.
What I cannot prove is whether or not there is any person anywhere that would consider these actual changes essential - I suspect that such a person does not exist but the inductive gap being what it is I might be wrong.
Bayesian analysis was originally formulated as a way to bridge the inductive gap, although that is not the way it is generally used, still I wonder at this point what the chance is that some of the data variances that have led to differences in AI conclusions are variances that any human would find inessential.
Maybe AI's are really being created to serve a special class of gullible human who don't understand basic epistemology.
interested to learn more about it, tia.
My answer is you could never know, because that is a testing problem, not an AI problem, and there is no test or set of tests that could settle this.
We certainly can have AI that seems to claim it is smarter than humans. But we also have idiot humans who claim they are smarter than humans, too. So what? Anyone or anything can make any claim, however untrue.
Imagine an AI that is smarter than most humans in terms of some technical ability but is stupider than most humans in terms of moral judgment. In other words, and automated sociopath. Please don't give automated sociopaths any power.
We got involved in an emergency "replace this component" job at work recently. When the inevitable "how are we going to test this" questions started cropping up we did describe how we'd made half a million automated tests and that we had a reasonable understanding of the < 1% failure rate.
It's important that a whole software suite be tested automatically for non regression with every change, even it the tests themselves have been written"by hand". Yet it is surprising how rarely this is put in plave.
Which, honestly, is a great argument for choosing languages with highly specific and derivable type systems: I’d rather deal with compile time errors than with writing runtime tests.
Well, because there are additional, unspoken, unconsidered rules that it wasn't programmed with.
For example, if the test always uses 1,2,3,4 and 5 as inputs, the AI could just generate a list that returns the results for those 5 but not any other.
It used to be that water levels were registered by someone manually noting the level at a gauge, writing it down, and bicycli g to the next. He'd visit all of them in a region in a day.
Now they're of course automated sensors. They are cheaper, there are more of them, they are more accurate, immediate available online, and with 5-minute resolution. Clearly better.
But the person doing the rounds each day would also see the whole system each day, notice vandalism, know local conditions on growth of pest water plants by heart, et cetera. Now there is nobody with such detailed first hand knowledge of the system. The informal part of the job is lost, and the loss can't easily be quantified as some amount of money either. It didn't even exist on the org chart, but it still feels like it was essential.
So we replace human work with different automated processes, and yes we ignore the true nature of the work.
Not exactly the same, but this is strikingly similar to some of the observations made in this essay: https://desystemize.substack.com/p/desystemize-1
When you reduce field work to a set of data, there's always something that got left out. You just have to hope it wasn't important. Sometimes it was.
Wim Lex, is that you!?
(And also, I agree with what you wrote.)
Yes the sensors might pick those up if they affect them. Put what's cheaper? pre-emptive "gardening"/maintenance, or rushing to get a downed pump station back online?
Having a team of people manually checking sounds wasteful. The 5% they miss is cheaper than the 95% more they spend.
There is a big push at my employer to eliminate single points of knowledge and this push typically takes the form of voluminous amounts of documentation that is 1) never proofed, validated, maintained, or updated, and which 2) no one ever reads. Makes more sense to have a solid continuity plan and create a work environment that doesn't cause employees to pull a Jerry McGuire. Probably also worth recognizing the value of observing the practice in action vs reading someone's opinions on it.
Humans aren't fungible.
How could you possibly ever know or prove anything like that?
In the area of testing, for instance, I study testers, and I document many things they do which require social competence to achieve. This is tacit knowledge. Tacit knowledge is not automatable. But when you don't know much about testing you don't see any of that tacit knowledge in action. So you think testers are just button pushers whose minds contribute nothing.
When OUTSIDERS to a process claim that they've automated it, they are always wrong; and not just wrong but absurdly wrong.
If you’re saying “it seems like people just want humans to be valuable, and the human race’s thinking seems very anthropocentric”, I definitely agree. It’s hard to separate a person’s inherent need to be important from dispassionate analysis in general.
Sarcasm aside, your definition is too low-level, as if we called brains just braincells. Pattern recognition is a building block of AI like a logic gate is a building block of a CPU.
We don't understand brains or braincells - how many operations per cecond can a braincell do? What type of operations? How many bytes does it store? We don't know.
Can we replace a single braincell with a chip and get them to act the same?
AI is not a single network usually, it is a pipeline of networks of different kinds, see e.g. https://m.youtube.com/watch?v=P1IcaBn3ej0 (seek to 1:35 for beginning of an architecture overview). You can’t call it “just pattern matching” without fetching it too far.
Have you considered all uses of AI or just a few that you encountered in your experience? AI automates lots of unpleasant manual work.
Github Copilot is a great example of this IMO. When you're writing code it seems to be on a 90/10 of 80/20 split where 10-20% of your code is the actual important bits that you have to pay attention to and the other 80-90% is all the common patterns, components and conventions around the important code.
AI is fantastic for the 80-90% of that code that I really don't care about. I can focus my energy on the 10-20% of the code that is really important and let the AI code the other 80-90% that is mostly glue and filler.
Meaning it is not the logical part you want out of the equation. What you want out of it is the unintelligibleness of code, the time it takes to writing all the necessary boilerplate of code itself, the bad naming conventions and stupid sintax errors...
When I start a new C# project, first 40 minutes I am mindlessly writing a scaffolding of classes, data structures and helper functions that I will need from the beginning.
When I start a new Clojure project, I don't need all that, so I just stare at my blinking cursor thinking about what the program will actually do.
I'd encourage looking through the documentation for Luminus[1], one framework for writing web apps Clojure, to help you figure out if it suits your personal tolerance for boilerplate. IMO the example for gating API endpoints by authentication[2] is remarkably simple, but you might prefer something more opinionated a la Rails to completely abstract the auth boilerplate away.
For what it's worth, being a lisp, Clojure could certainly support a framework for writing web apps that's highly opinionated, and takes in config for tweaking some defaults (e.g.: auth), thanks to macros.
[1]: https://luminusweb.com/ [2]: https://luminusweb.com/docs/services.html#authentication
I share this sentiment but the recently announced changes to file level namespaces, global imports, top level definitions etc. have the potential to eliminate a lot of pointless boilerplate.
Now the structural patterns - those are self inflicted - you pay that cost to keep the thing consistent and maintainable down the line - but people often can't evaluate when it's not worth it (and often even don't understand what they are try to achieve but instead treat it like boilerplate that has to be present)
Of course, if you can be specific about your misgivings that may help the C# (and Clojure) ecosystems or at least help us understand what you mean.
OO requires a bit of boilerplate and structure up front IMO, at least the Java/C++ variety. IMO the structure typically has to be re-invented each project as well. i.e. what factories, interfaces, parts will I need?
I think people seeking to automate software development should find out a way of compiling something like TLA+[0] to executable code.
Right now coders are both masons(brick layers) & architects. TLA+ is what can bee seen as a "blueprint" for code, and the actual code can be thought of as the brick and mortar.
Devs having to only focus on the blueprint of the code i.e specifications written in TLA+. Truly takes the industry forward.
Not sure how common this is today, but I do remember the time when software development was done by people writing hundreds of pages of specifications of various level of detail (including class diagrams, method names etc) and then delegating the menial work to very junior folks. In many cases I witnessed true contempt for the mere job of transcribing programs.
I'm not talking of some dark age of punchcards; but clearly learning the boring details of the Java SDK and figuring out how to setup your Eclipse project (let alone using CVS/SVN) was deemed to be below the pay level of many.
The quality of the software produced in those environments was abysmal. I'm not talking about specs on general, but the practice of making the mistake of overspecifying to the extent you think you need a quasi-mechanical transcription (an undergrad student or a very junior dev) but at the same time not really specifying everything and thus le
I remember having the same experience during my third job, in a french consultancy in Spain. For the sake of vindication (so many years after the fact xDD) I will just name it: Sopra [0].
So, for each business task (like adding some feature to the application we were developing), "Analysts" would write the "specification" in uml-like models in Eclipse (some kind of modelling plugin for Eclipse, I think it was a framework developed by the company over the EMF plugin suite), and a very short description of what this was supposed to accomplish, business-wise.
Our[1] task would be, then, to generate a scaffolding from these models (via Eclipse) and then to fill in the blank of the methods generated this way.
The problem lay at how the incentives were laid in that company (and many others like it, the whole IT "consultancy"[2] business, in fact) : Programming was a job that was poorly paid (but still, much higher than the median salary in Madrid, which is why I was there). So, every person had every incentive to get to either management or higher "design" roles (Technical Analyst, Business Analyst, Architect) as soon as possible. This meant that the people who remained in the company[3] were either the people that had 1 year, 2 year tops, of programming experience that got to now design whole systems and applications, or the sociopaths that floated to management by stabbing everyone on the way up.
You can imagine the quality of the systems produced this way...
Models were hilariously under specified, and clearly the person doing them did not have experience on how programas behave in real life. But because they were so insecure in their positions (remember the backstabbing and the lack of experience), any back and forth between the programmers and the analysts was handled with hostility and contempt from the analyst side.
Obviously we also looked at analysts with contempt. Still, they were paid better than us, so of course they were right and they had management support, and were told by our team leads to make it work anyway, so it was common to implement something completely different under the scaffolding, to avoid having discussions with the analysts, that checked that the scaffolding itself did not deviate from their designs.
So, my take in this kind of 5th generation (as they were called back then) code generation frameworks is that it encourages the kind of behaviour I saw. And when the same people that do the design also do the programming (the mason architects coders of our time [4]), this way of working is just redundant. Diagrams and models have their place in documenting a project, but certainly not in trying (and failing) to specify everything that can happen in a system.
Wow...I've almost written a blog post xD
-----
[0]: What a shitty place to work in, at every level. No joy was possible in that environment. Sociopaths thrived and naturally floated to the management positions. As we say in Spain: shit always float to the top.
I have so many stories to tell of that place...and I was only 6 months there!
[1]: lowly paid and lowly valued programmer-monkeys, literally the term they used when they thought we couldn't hear it (and for a more colourful spanish variation of it: "picatas" which was a derogative term meaning Typist)...how the tables have turned since then...
[2]: As we all know, it's just a sham. We were never consultancies, just the equivalent of cheap sweatshops for our french overlords, who came to Spain because programmer's salaries and labor rights were lower than in France. Still...they offered better salaries than the native "consultancies", so there's that. A common theme in Spain, actually. At least foreign exploiters treat labor better than our own national exploiters.
The situation has greatly improved since those times, and you can find genuinely good (foreign) companies to work at, in Madrid or Barcelona. The consultancies still exist, but they're no longer 100% of the job market now.
[3]: Because, naturally, the churn was stupidly high at the "picatas" level, who could find better offers and situations just by changing jobs every 6 months, which I did. I remember at that time how they tried to FUD us into "loyalty" by saying that they did not recruit people that had this kind of job-hopping CVs. It was false, of course, they were desperate to find people, so they took what they could. My father said the same to me. I don't doubt that was how it was at his time. That era of employee and employer loyalty had long passed by that time, if it ever really existed from the employer side in the first place (I doubt it, IMO it's just that employees had even less choice and were educated by society into loyalty for your task masters)
[4]: I'm very glad of how the industry has evolved, job-wise. These times are much more interesting from a technical point of view, than what existed in the past. I get enjoyment out of my job now, and that is priceless. Also the high salaries help. Not as high as outside Spain, of course, but high enough for a good life.
Sounds like a winner to me. Somebody should implement this!
The problem is that these approaches tend to fail whenever you need to either edit the generated code while not breaking the generation logic, or implement more complex logic and cases that aren't covered, or even just integrate with external libraries without digging too deep in the generation logic to assimilate the external code within the codebase.
Now, there are other, more limited cases in which this can work, especially with frameworks like Ruby on Rails or even Laravel, which provide all sorts of code generation logic for specific situations, given that they're typically not integrated with that many libraries, in which case they just make development faster and simpler.
Link to Ruby on Rails generators: https://guides.rubyonrails.org/generators.html (this does mostly describe how to write your own ones, though)
Link to Artisan make command (for models) in Laravel: https://laravel.com/docs/8.x/eloquent#generating-model-class...
Link to info about MySQL Workbench (both forward and reverse engineering): https://dev.mysql.com/doc/workbench/en/wb-data-modeling.html
Personally, i think that there's a lot of utility to be had in this approach, especially for situations like schema-first database development, or even generating migrations based on the model classes within the application. MySQL Workbench actually lets you generate DDL statements based on ER models, as well as synchronizing partial changes in a live database, which is useful in practice, yet also really niche and probably hard to implement behind the scenes.
Perhaps that's why sadly model driven architecture hasn't really become all that popular outside of academia.
Edit: i've added links to the tools i mentioned above, but also remembered that one of the things i've found most annoying about model driven architecture is that most of the work with models is forwards only - you can only go from a metamodel to a model and never the other way around. Ideally, there would be a way to take the current state of the codebase (with any metadata and also manually changed code) and generate a metamodel that can be changed as necessary, to later generate the model again but without losing the manual implementation.
But they seem the same.
> Meaning it is not the logical part you want out of the equation.
The "logical part" is what we call "writing software". The rest of it is window dressing.
> the bad naming conventions
Why do you expect an AI to come up with clearer names than a human can?
As opposed to building the code from the ground up, maybe we'd have to sculpt it from an amorphous blob into something more refined.
I guess coding manually would be something people do as a hobby, like solving sudoku.
Once we acknowledge we also need to delegate software creation to software you start abandoning the idea of a code review for something more alike to "correctness review", basically making testing your code review itself
And as you say manual coding would be done either by pleasure, nostalgia, teaching and most importantly identifying possible optimizations and errors
hard to know, economically-speaking...
How much less menial labor does one do with modern web frameworks relative to the state of the art in 2002?
Less was possible in 2002, so the menial tasks were different. But I think the split between interesting/novel code and boilerplate/menial work was about the same.
And yes I know WebAssembly is supposed to loosen JavaScript's hold on the web, but as far as I can see that has not happened yet even though every browser now supports it. I am not exactly sure why that is.
Since the bindings to the rest of the “essential” browser model are all geared towards js, the appropriate mental model might be that js is the “assembly” of the browser, even though it is not assembly in any meaningful compute/memory model sense.
If I look at any project I’ve made for the last ten years with « hype technologies », REST APIs everywhere, complex front end frameworks (so complex that it’s literally a second codebase), they totally could have been developed with an old and mature framework like Django, RoR or ASP.Net.
Once those projects are done, you clearly can see that : things like sending a form are incredibly complex and non standard, ressources are wasted everywhere, and only 1 to 3 APIs are used externally, and you maintain the dozen others for your own usage.
The sole reason we are on more complex stack is because the industry magically acknowledged that « web development » was in fact two different jobs.
It’s not hard to know at all, it’s a well studied area of economics.
As the cost of programming comes down, the set of problems it can be profitably applied to grows. So far, that’s been increasing the demand for programmers whenever the cost comes down.
It’s funny how this is true in several ways:
* Nobody needs to manually move the stack pointer anymore to implement a loop at the lowest level
* Iverson ghosts [0] let us operate on arrays without explicit loop constructs, e.g. array.sum() in NumPy
* Modern IDEs autocomplete loop syntax
I’m sure there are many other examples I’m missing. All of these are examples of automation of programmers’ work, even if we often don’t think of them that way (especially #1 and #2: higher-level languages/syntax)
[0] https://dev.to/bakerjd99/numpy-another-iverson-ghost-9mc
1000 programmers is more than 1000x as valuable to the world as 1 programmer. A million may be more than 1000x as valuable as 1000.
One programmer on their own has the maximum possible productivity per person because there is no communication needed. The whole project sits inside one person's head.
Of course, real world programs usually need more than one.
Each new programmer that is added also adds a little overhead to the existing programmers.
More, once the project starts to get really large, you start to get new forms of time wasting.
In a project with 1000 programmers, there is bound to be a huge amount of duplication, quite a lot of programmers working at cross-purposes to other programmers that they don't even know exist.
And there will also be programmers who do nothing, and get away with it in the mass.
And this is particularly true in open source, where there isn't any strong management at the top trying to prevent duplicate work.
Sure, now that we have more powerful, pipelined, branch-predicted computers and you don't have to optimize every last bit of your program, that's true.
Perhaps you mean the 1950s?
"Actual typing part" != "writing code"
I think that was 1982.
For me, a modern language like Python already removes 90% of the work I was doing in 1982, and templates and my editor do a lot.
It's really not clear there are huge speedups to be found there.
There’s people who get to own a problem and build stuff start to finish. And there’s people who are just automatons , implementing a specification. And everything in between.
So I think this can be absolutely true and false at the same time.
Maybe automatic esoteric language generation would be interesting - let a million brainfucks bloom.
It feels like an AI system could easily do a lot of this: what do I need? Some sort of web form which takes inputs, what do I need out? JSON which looks like this based on the inputs or database rows which look like this.
This feels accomplishable in the very near future.
in reality it works in a negative way. programmers hunt for un-automated stuff to automate. it’s like the state violence, that hunts for other kinds of violence. if you destroy all non-state violence, you end up with a lot of state violence to constantly perpetuate. if you automate all that is not automated, the only not-automated activity will be the activity of automation (programming)
Yup. This is pretty much how I describe my work to my wife. I find hard things and make them simple (using computers) - that makes "impossible things" hard, and inturn (eventually), I will make those things simple
Also if software development tools reach high enough levels, it may be that domain experts, or business analysts will do the development, and not software engineers.
A good abstraction, written for and suited to the task at hand, adds little complexity.
Reusing a previous abstraction, written for a slightly different purpose, incurs some complexity.
Having to use an abstraction, inappropriate for the purpose, incurs substantial complexity.
This results in three outcomes respectively: (1) increased productivity, (2) stable productivity, (3) decreased productivity.
Most of programming, in my experience, has been figuring out which one of those roads you're on, and when to eat the cost of switching to another.
I do expect that our abstractions will be sufficient enough that end users can express what they want in a way that doesn’t require deep knowledge…like building in a video game.
It seems like the entire article is based on this sentiment. I read the article but I'm not sure what the point it's trying to make is.
Even in this thread everyone appears to have a different idea of what automation is in the first place, and the author is basically suggesting that we will never have something close to the level of a sentient AI identifying requirements to produce a piece of code with no human involvement...?
I'm not well-versed in AI, and I'm not sure anyone on this planet is qualified to make a claim that we will never get even "close" to that point, but it seems reasonable that most of the things listed can be reduced to simple data and automated with well defined functions that transform them along the way:
* Specific tasks and activities
* Captures different data
* Can see or not see certain data
* Security — What can and can’t specific users do
* Different goals
* Individual responsibilities
* Processes
* Reports and visuals of data to decideI don't think the issue is that there isn't a tool that understands natural language, it's that even in natural language you need to specify everything before it works.
Who knows, though, maybe we'll see a piece of AI that can make educated guesses from rough descriptions and make it work.
Right. If we can build a strong AI, then we can certainly automate all stages of software development, by definition.
The article's argument essentially boils down to I have certain assumptions about the limitations of AI, and I've decided software development is one of the things that will always be beyond AI. It isn't a technical argument. It does a poor job of giving a solid justification. These sorts of arguments don't have a great history. From the article:
> Creating software is a human collaborative activity. Humans are good at working with other humans and with finding solutions. Computers can only automate using rules, but software projects have to work out the rules as they go along.
We already have AI that can do a surprisingly good job of writing English prose. A few years ago I'm sure people were making exactly the same kinds of arguments about how writing can't be ever automated because computers only ever follow rules.
edit In reality I imagine we'll see incremental progress, as we've seen with GitHub Copilot. I'm not saying we can expect to see software development automated overnight, but the idea that it's impossible even in principle for it to be automated, is not a position I've ever seen a good defence for.
So the question that prompted this was likely "What can I write on Medium?"
But you can't automate an entire business and you can't automate the entirety of software development either.
Is it possible to create a automated process that will with enough non-coding input create a workable software? In that regard answer is yes, same as developers are recording requirements, one day machine will have enough "knowledge/intelligence" to do the same.
Developers don't figure out requirements. sometimes it's possible to use libraries, Frameworks, open source and no code solutions or even modern programming languages to make that easier. However in general still someone needs fairly deep knowledge of the relevant tool. You might as well call such a person a developer. Usually very little in the sense of making it easier is possible because the software doesn't exist in a vacuum and needs to be build on top of/interface with/integrate existing software/run on a specific server set up.
Unless, of course, we are talking about a general purpose AI that can "think" like a human. But I think that's sci-fi for now.
Automating all of software engineering is something that will be done at the same time as every other job title - when general AI comes along. Hard to know when that might happen - it could be next week or it could be in 20 years.
The author is largely overstating the job of software development and confusing "software engineering" with "software development"
SE is indeed a creative process that requires a lot of thinking , conflicting point of view and a often a crazy amount of research in order to do anything ( Database System , CLI etc... )
But for the rest , I'm an enterprise architect in banking , 90% of the project I'm in charge consist of "gluing" service together or adding a "screen" in the front end that calls an apis...
Startups like Bubble|0] have proven you can create web / mobile apps / apis without code ,
the only reasons we are still relevant today is for three reasons :
- There is no proper FOSS standard ecosystem to create codeless APIS and Applications
- There is no standard in the industry for the business and application layers
- Enterprise have "legacy" that is much cheaper to maintain with humans ( Devs + Architects ) rather than automate by R&D to create those ecosystem ( Labor Capital Substitution )
There is dozens of papers on 4th industrial software revolution , which at the moment won't happen because the tooling is simply not there.
Definitely 4G Software ecosystem largely automate 90% of the blue collar coding of today.
People like you work in projects but us we dont just glue things together for your royal pleasure, we sadly have to actually fit a day to day need.
I used to be a consultant in this space, and I can confirm the existence of these completely different bubbles. Ironically one of the root causes is how badly banks want developers to be interchangeable commodities.
Many times the initiative comes from architects such as yourself.
I've never seen it go well, almost like they don't really know what it takes to "glue two apps together", but I'm sure you'll do better! Good luck!
Then how we automate creation of the standards? Don’t get me wrong, but now we aren’t punching holes in cards. In the future, people probably won’t be doing a lot of things, which are now typical menial tasks too hard or cheap to automate. As long as an AI with capabilities of reasoning and abstract thought comparable to a human isn’t here, there always will be a layer of tasks that is impossible to automate for one reason or another. Then it was card punching, now it is gluing APIs together.
Automation is mostly useful when you have a very narrowly defined process/standard with little variation over time. Unfortunately, this also requires for the one requesting the automation to know exactly what they want to get at the end of the process. How would one automate creation of a tool fitted to the particular way some business is operating? Video game development? Fixing badly documented code? Granted, many parts of those processes can be, and probably already are, automated away. But there are almost always elements that require a higher level understanding of the whole context these projects exist in.
I would equate it more to a hairdresser having switched from using scissors solely to being able to use a hair clipper. Their work was partially automated by a machine, but the process still is overseen by a human being.
Much of the automation happens when you do know explicitly what the goal is. However, for programmers, their job is not turning well-defined steps into valid code but understanding what the goal is from very vague requirements, and that cannot easily be done by a statistics-based ML algorithm.
The absolute vast majority pf software development is barely one step away from a CRUD. Do not deceive yourself thinking that developers solve some incredibly difficult problems unknown to mankind.
Your "vague specification for a form" is right now being solved by about 100k other developers. It's not unique.
Your 100k other developers will continue to justify their positions to improve the model though.
(Ah, I see the sibling post linked to it, and it's not xkcd which explains why I didnt find it)
Once one of a kind, now pumped out by the millions in factories.
There is an idea of 100% automation, with the computer spontaneously generating a program that both meets the users requirements and is delivered to them when they need it. This is unlikely without some degree of human intervention to at least state, "I need to...". If this is what the author means, then sure, they're correct. This is such a fundamentally absurd idea it would be impossible for me to even conceive of an argument well-grounded in physics and computational theory that could support it.
However, here's my take on automation in the domain of software development that doesn't sound totally absurd and is probably closer to what most people mean when they describe it: A system in which a user can provide a minimal specification and get a complex execution as a result. I offer SQL query planners as an example of this. The user needs to enter "SELECT * FROM foo;" and the planner does the rest. The user doesn't need to do anything else (optimizations notwithstanding). From the perspective of an intelligent data analyst but "non-programmer" (in their perspective at least), the program is automatically developed to meet their needs from this point forward. It is a reasonable response to say that the SQL query is a program, but it is such a minimal specification of a program that the specifier can be totally unaware of whether the database is on their machine, in their local network, on the other side of the planet or on Mars, if it's a single database or sharded for performance, or any number of other considerations. The development process has been automated beyond this level of abstraction: The user merely needs to know the relational model of their data and the syntax of SQL and they can accomplish grand things.
Now, the rest of this gets a bit nitpicky and at some point I started to feel like a real asshole so I didn't finish the paragraph by paragraph rebuttal (aside: paragraphs should be longer than tweets), also it got too long for HN and on submission it told me so. Keep the above idea of automation (mine) in mind, because if you keep the straw man version in mind then the author is, of course, correct. But it's also a kind of useless way of being correct when the notion you're responding to is so fundamentally absurd.
> As much as people would like to automate software development, they can’t because it’s a creative and collaborate process.
Which people and to what extent do they mean to automate it? You've posed that they exist, explain who they are or at least what they actually mean or provide their words so that we can understand the context of your article.
> It’s uncommon to think of developers as creative individuals but more technical people writing code. The common belief is developers take rules and automate them.
Is it really? At least on this forum it's not. I mean, I do get this from managers at times. I had one who said, only loosely paraphrased, "Software is easy, you just have to type. Why is this taking you so long?" Fortunately they seem to be a dwindling group in my circle.
> Developers can only create software to do what you tell it.
This would also be true of a program synthesis tool.
> You can’t automate creativity and where the final software is unknown.
I mean, I guess it depends on what we mean by "creativity". What is creativity? Per Wikipedia we get this sense of the word: Creativity is a phenomenon whereby something somehow new and somehow valuable is formed.
Huh, a phenomenon whereby something new and valuable is formed. I'm pretty sure program synthesis is a thing. Now, you could argue that providing the requirements and letting the computer generate a program from them is in fact an act of programming. I think that's reasonable, but it would be a significant amount of automation. To be able to go from a mere statement about what a program should to a program that does without any more developer interaction would seem to be automating software development to me.
In the section titled Why can’t you automate software development the author concludes with:
> You can’t automate the creation of software because the requirements are not known.
The rest of the section has no relation to the heading. I reread it several times trying to figure out how those sentences and bulleted items related to it, but could not. Maybe someone else can tell me how. The only relevant piece is the sentence I quoted. To which I'll say: Umm, no.
The requirements may not be known in full, and they may not be known at the start. However, this statement is presented as a universal truth, when it is not. I know the requirements for my software at work, but perhaps that's just because my customers know the requirements for the software. They know the requirements because they know their domain. They know the systems they have to interact with. They know the tasks that have to be done and consequently know the tasks and features they need us to implement. I'll admit, this may be a rare situation, but it's not unique.
All that said, if the requirements are not known for your system, then certainly you can't automatically create it because you don't know what to create. You can't ask a computer to synthesize a program that you can't even describe. That is a reasonable statement.
> You can’t automate the creation of software because it needs to work in a way that makes it easy for the people to use the software.
The former does not follow from the latter.
> Software is a tool to aid people working, to help them to their jobs. The goal isn’t to make software; the goal is to make software that makes work easier.
I can agree with this in a general sense. Making software is rarely the objective itself, it's true. Making software that accomplishes some meaningful work is the more typical goal (especially in businesses where there is a dollar amount associated with the work). Nothing to do with automation, though.
> You don’t know how software needs to work until users use it because many of the rules in a company will conflict.
Two things here:
First, finally you express your domain. Business process software, which is perhaps one of the software domains closest to being automated. BPMN has been around for a while, and not really caught on as much as Appian and others may like, but if you go with my notion of a minimal specification, this is a domain ripe for automation.
Second, if you don't know how software needs to work until it's being used then you don't know what you're making. We're back to my earlier statement, you can't synthesize what you can't describe. Short of a stochastic method which synthesizes many programs, at least, for users to test out. Genetic programming BPMN could be entertaining to observe as chaos spreads through the organization and BPMN diagrams are mated and mutated.
> Actions and software can have unintended consequences that are only visible when they happen and then you decide to change the software.
> Businesses evolve, changing and adapting to improve the way they work. Software goes on a similar journey when you create it. What seems a great idea on paper or as requirements might not work as software.
Program synthesis does not bar evolution.
> Finding out the final requirements and how software should work is the journey, it’s the creative process that involves many iterations. You can’t automate creativity because it can’t be broken down into steps and rules.
Again, depends on your notion of automation. If it's the spontaneous creation of just the right program, sure. But if it's about having a minimal specification that can then be used to synthesize a more complex program, then you can iterate on that specification itself. Without needing to get into the lower level systems (again, optimization notwithstanding).
> You can’t accurately plan how long it will take to create software because you cannot say exactly how the software needs to work or how many iterations it will take to get it right.
Not related to automation or lack thereof. See Swift and the exploding compiler times.
> Software developers take the requirements and create what they think the users need. The users then use it and give feedback. There is subjective and there is interpretation and assumptions that lead to the wrong software created.
No reason that a computer can't take the requirements and create what it thinks the user needs (per the mechanisms provided to it to produce a working solution). No reason that a user can't give feedback to a computer.
> The wrong software is progress because it gives us some definitive to build on and update. This is a step towards creating the correct software.
Good news! Automation is almost certain to make the wrong software at times, also giving us something to build on and update.
- Thomas Watson, president of IBM, 1943
"Too big to fail"
- Titanic, and some banks, 1912 - 2008
"Don't worry, the software labor market is safe" - 2021
Reads the same? With a different meaning tho. Meaning's important. That's what we're doing here: meaning.
No
1) The kind died, then the queen died of a broken hard.
2) The king died, then the queen died.
3) The kind died, then the queen died of a broken arm.
One is a story, two is not, three is written by AI.
PS: I laughed more from the xkcd link posted before by u/ignoranceprior https://xkcd.com/1263/
But seriously, no GPT is not going to be writing movies any time soon. Why? Because it does not have anywhere close to the coherence of human written plots. Why? Because GPT is not "AI." It is rather fancy statistical extrapolation.
We should be defining intelligence by outputs rather than the methodology by which they achieve them, or else the only acceptable definition for intelligence will become "a human brain".
If you choose the former, you can comfortably say airplanes don't fly, they just glide, if you want to define flight as flapping of wings. Yet airplane flight is more efficient than if we tried to achieve it the biological way.
Similarly, it seems apparent we'll be able to solve many tasks that we attribute to "intelligence" using methods different than the biological ones. We shouldn't limit ourselves to comparing the methodology when deciding if it has achieved the goal, it is more productive, from what I've seen, to define by output, and to increase specificity there if the result is still unsatisfying.
Thinking is an internal process. It is not just determined by its output. When we roll dice we do not say the dice decided to land on three and seven.
That's not true, at least a lot of the time. Watch an episode of Paw Patrol, go see the latest Marvel movie or listen to number 6 or 7 on the top 40 charts.
A huge amount of what we consider "creative" endeavours that only a human can produce have nothing to do with meaning or experience and are simply a group of people trying to create something that "sounds right" or looks cool, or in the case of a lot of kid's content, merely inoffensive to the largest segment of society possible.
I'm not saying that GPT is going to win the Pulitzer Prize any time soon, but the line between "human text has meaning, machine text doesn't" is quite blurry and process-dependent.
Kind of like the old joke about English teachers looking too deeply into classic literature, isn’t it? I might not intend to relate and extend layers of context with the line, “John sat squarely on the desk,” but a reader observing that line as part of a surrounding text could infer meaning and purpose beyond what I originally intended.
With AI-generated text, that dance of writers filling (or deliberately avoiding) their work with meaning, and readers lifting the meaning out of the work, becomes much less human in and of itself. Or does it? Will schools of the future choose AI-written stories and film for students to learn from, over material written by people?
I don't see it replacing their writers, but I see their writers using something like it to mine ideas from on a particularly long night around the writer's table.
It requires creative input. It's just remixing what it already knows. Once you've exhausted that you're back to needing human creativity again.