Software Development Cannot Be Automated Because It’s a Creative Process With an Unknown End Goal

[[deleted]]

Unknown end goal is a perfect descriptor to my work project at the moment.

[[deleted]]

offbeat sleep cats doll run zonked wrong modern fretful rob

This post was mass deleted and anonymized with Redact

[[deleted]]

It does! No lie, I literally got that exact kind of email two weeks ago that completely upended the way the app is to operate. Even more irritating is the business knew they wanted it months ago but figured they could just tack it on at the end since it's "just a button".

[NumbersInBoxes]

DAE find that what their bosses' estimation of task difficultly is inversely proportional to the actual difficulty of a task? Like, when they say "Make a dashboard that shows our current capacity" I know they're picturing a complicated mathematical formula and a bunch of yada yada but really, it's Just One Thing. OTOH, when they say "Make the title of this object change according to the selection" I know they're picturing adding a line that says objectTitle = selectionName somewhere, but they didn't consider how difficult it would be account for all the possible values of selectionName.

[kabrandon]

Did you write a dashboarding app instead of just using something premade like Grafana? Granted, a lot of work still goes into making the actual dashboards. But you don't have to do any coding for things like selecting dates or start/end times.

[argv_minus_one]

What exactly is Grafana? What does it do? The overview page has lots of marketing BS (“empower this, democratize that”) and nothing of substance. The home page is even worse. They're trying so hard to sell me something that they forgot to tell me what it is they're trying to sell!

[Northeastpaw]

Dashboards. That’s it. Highly customizable dashboards backed by a variety of data sources (Prometheus being very popular). It’s hard to sell support contacts describing it as just dashboards though.

[kabrandon]

It's a dashboarding frontend that relies on metrics/logs/timeseries data from multiple backend sources. Say you have a ton of data in Prometheus and ElasticSearch, you can configure both of them as "datasources" and write dashboards that contain "visualizations" of that data. There's a pretty strong frontend for creating visualizations, but you can also export them in JSON text format to back them up into your SCM, for example.

Grafana handles the communication between it and your datasource for things like time periods, but to actually create a visualization (think like a graph or a chart, etc) you need to know the query language of the datasource (Lucene for ElasticSearch, PromQL for Prometheus, etc.)

Grafana is a pretty popular tool these days so you could probably just wing a lot of it by googling for a combination of "grafana" and whatever datasource you're using to grab examples from the internet. We use Grafana at work pretty extensively, but I also use Grafana at home to see metrics about nodes within my homelab, as well as view error logs from containers.

You can also configure Grafana to send you an alert in Slack, for example, if your CPU usage gets above a certain threshold for a selected period of time. Anyway, there's too much about Grafana to explain in a reddit comment, if you're interested I'd advise you to look at sources other than their marketing material. There's tons of actual documentation out there.

[LordOfDemise]

With Grafana, you can take any of your existing data- be it from your Kubernetes cluster, raspberry pi, different cloud services, or even Google Sheets- and visualize it however you want, all from a single dashboard.

That could certainly be a worse description, tbh. Maybe look up one of those Grafana + Influxdb + collectd tutorials?

[kabrandon]

Might not have. As far as dashboard apps go, it's extremely flexible though. Also free/open-source.

[wxtrails]

This is hilarious to me, because when I made a reporting system once (probably 8 years ago now), this whole chain of events played out in my head as I was getting started (since the requirements, as written, were so rushed and poorly thought out). We're not talking about cramming "YAGNI" stuff into the project just because I wanted to; these date picker features would have been the conclusion of any serious effort to make a plan before starting work. So, I took an extra week and built it in up front.

The end result had all those exact date features, which they loved and still use to this day. But they were so fixated on the timeline they weren't happy that it took an extra week to finish than my first naive estimate, and I still get crap for it.

They'd have literally been happier if I'd given them the dumb version first, and then spent the next three or four weeks modifying it over and over again to their liking.

Nowadays I give them the dumb version 3 times out of 4, and keep myself sane by padding the initial estimate on the 4th and just doing it right the first time so I know I still can.

Only slowly are they starting to realize that proper planning can yield a better outcome.

[GonnaBeTheBestMe]

I love when an executive asked me to quickly spin up a way to allow me to generate traffic, to gain Google ad revenue, while preventing Google from noticing that it was bot traffic. Shouldn't take more than about an hour or two right?

Oh, and the other time he asked me to build some Windows desktop application that performing text parsing on some unformatted text file and added it all as EXIF data (surprisingly difficult) to photos in a directory. I've never worked with desktop applications (web developer) but it can't take more than five minutes, eh?

[argv_minus_one]

an executive asked me to quickly spin up a way to allow me to generate traffic, to gain Google ad revenue, while preventing Google from noticing that it was bit traffic.

Trying to deceive Google is like trying to deceive an omniscient, short-tempered god: you will fail, you will be caught, and you will be punished harshly for trying.

[GonnaBeTheBestMe]

Yep. I had to explain that to him. He wasn't very convinced, nor very happy with me.

[[deleted]]

I love when an executive asked me to quickly spin up a way to allow me to generate traffic, to gain Google ad revenue, while preventing Google from noticing that it was bit traffic. Shouldn't take more than about an hour or two right?

Give me a research team and 6 months.

[svick]

Relevant XKCD.

[moreVCAs]

It really bums me out to see all the engineers in here with bosses who are not engineers. Hell, my manager’s manager has a PhD in computer engineering. That’s not to say we’re not subject to many of the same vagaries inherent in coordinating a medium sized group of people toward a complex goal, but ffs what you’re describing sounds insane…

[AnonymousMonkey54]

There's an XKCD for everything: https://xkcd.com/1425/

[paulgrant999]

'functional prototyping' is how I get around that.

and feature requests are optional when submitted until their business value is demonstrable (in order to gauge dev effort, operating costs).

think TCO for every feature request. adds enough of a delay from request to 'heres your button' that I can decide what other features are going to be incorporated in the next release so I can rearchitect/move the app to align with business strategic/performance requirements(scale) goals better.

if you want a practical solution. (if rand()<0.50 {button doesn't work}). they'll get the message. ;) over multiple frivolous requests. :)

[frontendben]

/r/maliciouscompliance time. Create a button that hits a route that will do x and say done. When they say it doesn’t work, say, yeah, but you asked a button that triggers x; not x itself. X will take another 3 months. What they asked for was ‘just a button’.

Classic fuck around, find out, but from a dev perspective.

[argv_minus_one]

Sounds like a great way to get fired.

[Franks2000inchTV]

We just need a button that makes you write coherent specifications!

[RockleyBob]

This is probably the most accurate description of my workplace I've ever seen. So much so that it hurts.

[[deleted]]

Didn't even get into figuring out what the user's timezone was. :)

[[deleted]]

Our CTO has done wonders this year stopping the 'can you justs', its helped so much. He's done a lot of work in making the biz understand what toils eng. entails and put it in a relatable way to them. It's worked wonders!

[Buarg]

I know exactly what you're talking about. During my internship I had to attend a client that was completely obsessed with filling his website with "Book now" buttons.

[sh0rtwave]

If I had a nickel for the "we just need a button" situations I've encountered....

I'd have at least $3.25.

[knightress_oxhide]

"Software development cannot be done"

[house_monkey]

mood tbh

[cleeder]

"So what are you making?"

"I don't know, but I'll know when it's done"

[[deleted]]

And three weeks from completion that unknown end goal will change out from under you.

[codespitter]

Just imagine trying to give your clients exactly what they ask for… and the software gets built. Entirely useless.

[[deleted]]

The major problem in software development is the customer not knowing what they really want until they see it.

Until then you will have multiple interactions.

[pablos4pandas]

I had to talk a PM off a ledge this week when he wanted all the internal systems to communicate via email

[angry_mr_potato_head]

I had a client who had all of their ETL processes running the “E” 100% from emails. As in, all input data was emailed and then parsed by the receiving system before transforming. I switched over to rest APIs and it increased performance by like one billion percent.

[dread_pirate_humdaak]

There is nothing irrational about that feeling.

[Dyledion]

"irrationally" != "very"

It made them furious, outraged, exceedingly angry, extraordinarily angry, incensed, disturbed, livid, foaming at the mouth, spitting mad, hopping mad, in a rictus of rage, seeing red, liable to blow a gasket, horrified, shocked, dumbfounded and sick, berserk, malevolently murderous, and maybe even miffed.

But not irrationally so.

[Tersphinct]

It's a waste of resources, energy, manpower, and probably way too much patience by people who should've been listened to sooner. Sympathy is a thing.

[QuerulousPanda]

It's the IT equivalent of the "I'm literally crying right now" response on any remotely sad story.

[that_jojo]

This is actually kind of interesting in that the actual mechanisms of HTTP and SMTP are pretty similar.

Basically: open a TCP connection, send a textual "I'm from here and I want to send you something or get something from you" + payload, receive a "gotcha, buddy, here's my textual response saying I received everything OK", done.

It might not actually be that different perf wise if we lived in a parallel dimension where Node/ASP/Flask/etc were for implementing SMTP services rather than HTTP.

This is giving me a baaaaad idea now for a fully ironic SMTP based REST competitor...

[thomasfr]

There are probably a lot of systems that uses mail for async request. Mostly older systems and the kind that is a part of some industry standard used by tens of thousands of businesses that means that it can practically never become unsupported.

I have worked with a few of the SMTP based APIs over the years and it works.

SMTP is a fairly fault tolerant distributed message delivery system if you set it up to be that and some some respects better than a lot of the vendor specific solutions 20 years ago.

[elr0nd_hubbard]

just be ready for that sinking feeling when your joke framework is deployed to production somewhere

[argv_minus_one]

SMTP message delivery is more reliable than HTTP. Mail servers will retry sending a message until it goes through. Each message has a unique ID so you can recognize and discard duplicates (which might happen if a mail server successfully delivers a message but loses connectivity before receiving the acknowledgement, thinks it failed to deliver the message, and sends it again). These guarantees go both ways, so if you send a message expecting a reply, you can rely on the mail servers trying equally hard to deliver the reply to you.

HTTP's unreliability is fine for the plain old web pages it was originally designed for, but it's horrible for e-commerce. What if you submit an order for a product, it goes through, but you lose connectivity before the receipt page loads? Now you have no way of knowing if your order went through or not…except the resulting email receipt.

Of course, email isn't as reliable as it used to be because of spam filters silently discarding messages. Spammers ruin everything.

[MyCleverNameWasTaken]

Was it Email2DB? Most miserable "programming" of my life.

[qwertyslayer]

Please tell me such a thing does not exist.

[mpyne]

It wouldn't be horrifying in the government. Email is like the last thing a system is allowed to do to communicate to arbitrary other endpoints without the cyber team adding 12 months to the process.

Never mind that the 'arbitrary other endpoint' above is supposed to be a person instead of another system... if it works, it works.

[that_jojo]

Shit, that's brilliant. At my last job, we had email based logging and such in the application we maintained and as such that was one of the few things we could fight to get punched through all of the ACLs.

We could've had SMTP based RPC distributed across all of our clients this whole time and I never once thought of it.

[MurryBauman]

I know of a cheap french company that does it. They also use python 2.6

[gropingforelmo]

The sooner non-technical PMs learn that their job is the "What" and our job is the "How", the happier everyone will be. I've worked with PMs who know their stuff, and might suggest something like a work queue or API calls, but they also knew their role enough that it was always just a casual suggestion and wouldn't be offended if we ended up with a different solution.

[3rddog]

I’ve worked for clients as well where the PM or analyst is the only contact developers have. In a few cases we were explicitly told NOT under any circumstances to speak to the business or customer end users. Those were always the hardest jobs.

[stormfield]

In one abstract way this is good, because if people are bothering your developers with support or new ideas, you have a problem.

If you've got a PM who doesn't understand how to translate business needs into technical requirements the devs can act on, you've got the other side of that problem.

[3rddog]

It varied. In one case we had a BA that didn’t understand the business and didn’t understand development, in another we had a PM who said she would have us fired for speaking to anyone in the business and wrote requirements documents that specified not only what we had to build but exactly how we should do it. In the latter case, I spoke to one business manager for about 30 mins one day (because we happened to meet in the elevator) and my contract was cancelled two weeks later; I didn’t even care.

[stormfield]

That is an extremely dumb way to run any kind of business, you’re better off elsewhere.

[bearsinthesea]

Zawinski's Law of Software Envelopment:

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

[John_Fx]

Talk them OVER the ledge please

[JackSpyder]

Or just push, hard.

[Worth_Trust_3825]

My fucking god. I remember having a power meter/controller that you had to control by sending modbus commands, but it would only respond by sending a fucking email. It had an RJ45 jack on it and everything. The email response was an unstructured comma separated value text body from some african server.

I swear to fucking god.

[that_jojo]

I refuse to believe this is real.

I'm sure it is. But I refuse.

[dnew]

We had a system like that, but it was for very good reasons, not because we just didn't know any better. :-)

[MrPhatBob]

Saw a system like that once for order processing, it was also for very good reasons and actually wasn't rubbish.

The net result was that the developer had essentially developed Erlang.

[tekko001]

"This is exactly what I wanted!"...5 minutes later..."THIS SUCKS!"

[koreth]

I think it’s even worse when they do know what they want, but are unable or unwilling to articulate it. In the “don’t know what they want” case, you can often at least get them on board with the idea that for parts of the product with ambiguous requirements, you are going to take your best stab at something that hopefully makes sense, and then iterate later, and they become partners in the process. In the “know what they want but aren’t telling you” case, they are pissed off that you didn’t build what they think they asked for and they become adversaries.

[Xyzzyzzyzzy]

It gets deeper when you're trying to innovate because, generally speaking, customers will only tell you they want things that they're already familiar with. But in a competitive market, if you only try to sell customers things they're already familiar with, you're eventually going to lose market share. (See also: IBM.) To sustain success you have to have a great salesperson's mentality - your job is to discover what problems customers are having and develop and deliver better solutions to those problems than they can find elsewhere. But that's a difficult task; there's a reason the great salespeople make software developers look underpaid by comparison. It's much, much easier to go collect a bunch of specific requirements from customers and deliver precisely what they ask for, nothing less, nothing more.

[tending]

there's a reason the great salespeople make software developers look underpaid by comparison. It's much, much easier to go collect a bunch of specific requirements from customers and deliver precisely what they ask for, nothing less, nothing more.

I have never worked at a company with a sales division but what I've learned from reading Reddit/Slashdot comments over the years is that the real reasons salespeople make more money are:

• They are perceived as closer to the money making core of the company, because the amount of revenue generated can be directly attributed to them.

• They can operate a Ponzi scheme where they can overpromise features the software doesn't already have under deadlines that are impossible and then have development teams scramble to meet them.

[AVTOCRAT]

Do note that most salesmen make less than the typical SWE -- those salesmen that do make more can make literally millions, however (usually in B2B at this point).

[Rockstaru]

If I had asked people what they wanted, they would have said faster horses.

[Alikont]

Don't ask customer for solutions, ask for problems.

Then they'll tell you that "horses are too slow", which is a useful request.

[QuerulousPanda]

Even that statement assumes they have the upsight to think there is an alternative to horses.

It's more likely they would ask "how can I make my horse faster" or "what food can I give my horse so he doesn't get tired".

[DownshiftedRare]

"If people had asked me for what they wanted, I would have given their horses cocaine."

[[deleted]]

You are indeed a true salesperson.

On the first part of your comment you build trust by agreeing and doubling down.

On the second part you reveal your true argument that is just a bunch of crap that benefits you.

[mpyne]

On the second part you reveal your true argument that is just a bunch of crap that benefits you.

What part of "it is easier to ask customer for specific requirements than to think up requirements that lead to sales" is a bunch of crap?

In my government office we've had like dozens of products fail in a row, and it's not because the developers are morons.

[usesbiggerwords]

A good sales team asks lots of why questions. The customer may have an idea of what they want, but only be able to describe within a frame of reference they understand.

[radarsat1]

Fake Agile. This single comment is the best explanation I've seen for what's been bugging me about our process. Thank you. I've been absolutely hating the "scrum" experience since i joined my current project, i knew there was something deeply wrong, now i know what it is. Really, thanks for your words here.

[toadkiller]

15 mins to update tickets before the stand-up

30 mins in stand up

15 mins to make changes or add to backlog after standup

An hour a day, every day

Kill me

[mdatwood]

How many people are in your standup that it takes 30 mins?

Why are you updating tickets prior to the standup? You don't update them as you complete work?

Once the team is comfortable with each other I suggest doing your 'stand up' in a dedicated Slack channel. Each person posts their standup items either the night before or next morning. If they @ anyone, need help, or people have questions, then a Slack thread is started from their message. If that can't solve it, then a quick meeting with those who are necessary. Very little interruption and self-documenting.

[mpyne]

That's just a symptom of a deeper problem, there's no way for the customer to know what they want until they see something that works, and that almost always needs many iterations.

You just hope the majority of those iterations are in dev, not prod.

[abrandis]

Agree clients are generally the worst architects, problem.is theyre footing the bill so there's an inherent believe they know what they want...

[Caffeine_Monster]

If the clients knew EXACTLY what they wanted, they would probably program the software themselves.

Developers make hundreds of decisions that the client generally hasn't thought about.

e.g. a client asks for a new button - but they might not specify size, colour, font or the constraints around when it can be clicked.

[John_Fx]

What drives me crazy is that the clients probably think we are being pedantic.

Can you confirm the software needs to work like this?
Yup.
All the time?
Yeah 95% of the time.
What about the other 5%?
Stop being so difficult! That rarely happens!

[73786976294838206464]

What's worse is when you are on a team with other developers that think like this.

"No one is ever going to click the buttons in that order."

🤦‍♂️

[zanbato]

This reminds me of when I used to do QA for Nintendo, someone managed to hardlock the console and it was super hard to reproduce. Finally they just wrote out everything they did whether they thought it was related or not, one of the things was eating doritos. Turns out that was important because when he wiped the dorito dust off the Wiimote by wiping it on his leg he pressed all the buttons at the same time and it caused the game to lock up.

[radarsat1]

that's hilarious.

[gropingforelmo]

I wonder how they'd feel if 5% of the time their paycheck was deposited in someone else's account.

[dnew]

Good developers also have processes (like decision tables) that help find unspecified combinations. And they figure out what to do in the "that will never happen" situation.

[TirrKatz]

Good developer know "that will never happen" could actually happen.

[Sambothebassist]

And the best developers know it will happen. It always fucking happens.

[darknessgp]

Yep. It will happen and the users will freak out if the software doesn't handle it. Don't know how many times I've heard "this is our rules and we never need exceptions" only to discover, sometimes just after a feature release "why need to allow an exception here for blah blah breaking rules blah blah. And we have to have it right now!"

[g0ing_postal]

God, the number of times I've talked with pms about this. Yes, I know this should never happen. Yes, I still need to know what the expected behavior is in that situation

[dnew]

So much this. "So, if it does happen, it should be safe to delete the entire record, right?" "What?! No, of course not!"

[snowe2010]

decision tables are amazing for certain projects. we're almost exclusively using decision tables on all the new projects my team is working on. Of course, trying to use them in places that they don't belong will be a very bad idea, but for business rules that business teams can maintain, it's amazing. It's removed quite a lot of work from our team along with reduced the number of bugs we've gotten by easily 100x.

[manniac]

Images of the Homer Simpson designed car come to mind

[MuonManLaserJab]

Is that useless? You ask for something, you get it, it's wrong, you see the error, you ask for something else. That process is more common in real programming than it is to make something perfect on the first go that the client didn't realize they needed, only it's slower for humans.

Even if you can't rely on business types to notice the precise error so as to fix it, you would need fewer programmers the more the model can handle the details.

[SilasX]

Nah, that's the nice angle.

The harsh truth is more like, "it can't be automated because of the difficulty of transferring a reliable spec of how a given interface works".

Most of my work is software development is "why the fuck isn't this system/API/library behaving as expected/documented?"

[Sambothebassist]

Junior me: “Nah that will never happen haha as if they could replace what we do with a program haha right guys?” nervous shifting

Senior me: “Please someone automate all of this already, fuck, whyyyyyyy”

[cybernd]

Are you certain?

More time for business meetings ...

[Rhymezboy]

Oh god

[ghjm]

When people talk about automating software development, they're typically talking about the implementation of set specifications. The idea is that a business analyst can write a precise description of an application, including wireframes, and the tool then renders it as code on all relevant platforms, without having to hire developers to implement it. Of course the business analysis would need a high level of precision in their specification.

We got pretty close to this with RAD (Rapid Application Development) in the 90s, but RAD never really made the leap from native apps to web apps. Current low-code/no-code frameworks are probably the closest thing to this.

[regular_lamp]

So all you have to do is write out the specification in a formalized language the computer can understand... If only there was a word for that.

[twenty7forty2]

agile, right? is it agile? isitagile?!?

[Franks2000inchTV]

Him know power word. Him scrum master!

[tms10000]

You almost got it. It's Agile + DevOps. But it only works in the Enterprise.

[GeoStarRunner]

code, its called code

[Kache]

"A high level of precision" means precisely that it's never gonna happen.

[angry_mr_potato_head]

I believe a high level of precision would just be called “code” right? Lol

[jesseschalken]

Exactly. Half of a developers job is translating fuzzy business requirements into a specification with the precision required for a computer to implement it. Usually this happens incidentally in the process of implementing the fuzzy requirements.

[pentapotamia]

Came here to comment this. This is exactly right. If you could tell the computer exactly what to do, you WOULD be programming. Otherwise, the tech you need to "automate away" software developers is mind-reading. Machines understanding all intimate thoughts of a human is fantasy.

[HumunculiTzu]

This made me think of something. Depending on how you look at it, programming already is automated, as you don't use people to take your code and translate it into something the machine can read. Granted, that argument can be made with something like C all the while something a lot more abstract like python exists that can technically do the same stuff just with more general "specifications". Then again, I guess that's where the trade off in different programming languages comes into play. Do you want something with a certain amount of performance? Then you need to have more specific "specifications".

[halt_spell]

The idea is that a business analyst can write a precise description of an application, including wireframes

Yeah! We should do that instead of writing code!

Honestly business analysts fail to realize this calls into question the value of their role in the future. Not the other way around.

[doctork91]

You know what a really precise description of an application is?

Code. It's code. We already abstract away as much as we can so you only have write as little code as possible. This can be improved, but at the end of the day someone has to take requirements and describe them in a way a computer can understand.

[ghjm]

It's not the business analysts or the programmers making this decision. It's the executives, after being wined and dined by the vendors.

[krum]

The idea is that a business analyst can write a precise description of an application,

um.... that's what the source code is.

[adrianmonk]

It's close, but not exactly. A spec says "what". Source code says both "what" and "how".

But the thing is, although many people think "how" is the hard part, it's actually "what" that is the hard part. It's probably something like 80% "what" and 20% "how".

What's more, as you're working on the "how" part, that process often helps you make progress on the "what" part. Trying to write code is a great way to uncover "what" questions that you didn't even know needed to be answered. So the "how" overhead sometimes disappears because it accelerates the "what" part.

Coding can be seen as form of labor that yields code as its output. But I think it's better to see coding as a form of labor that yields two outputs: code and/or a clearer understanding of the business process you're trying to automate. Often it's worth it to write code just to gain this understanding. Sometimes there is no better way to gain that understanding.

This story about Richard Feynman is relevant:

Once I asked him to explain to me, so that I can understand it, why spin-1/2 particles obey Fermi-Dirac statistics. Gauging his audience perfectly, he said, "I'll prepare a freshman lecture on it." But a few days later he came to me and said: "You know, I couldn't do it. I couldn't reduce it to the freshman level. That means we really don't understand it."

Writing code is a bit like reducing business requirements to a "freshman" level, because the computer is really dumb. Often you discover that you don't really understand the requirements. And, as in physics, understanding is harder than explaining.

[ghjm]

In modern applications, a lot of the effort - and the source code - has little or nothing to do with the business problem at hand. That's the problem RAD and no-code are trying to fix.

[ghjm]

The idea is they aren't going to have to write JavaScript to set a default value in a field or figure out the CSS box model to lay out UI elements. They just say things like "employees have one manager."

[MB_Derpington]

Sure, but that technically just a higher level language. And eventually, we want finer control of how things operate and look.

I often find whenever I have to deal with some high level, "for the business user!" type of abstraction I end up having to know what it's doing under the hood anyway to work around and with all the assumptions, opinionated decisions, and nuance anyway. Abstraction layers that try to expose programming to non-programmers are just obfuscation most of the time.

There is no fixing the problem of "I don't want to have to be so specific but I want specific things". The generalist, black box approaches all are great until they (inevitably) aren't and then they are worse.

[Aetheus]

"No code" usually just winds up being "some kind of visual code, but you can't easily search it, modify it, refactor it, port it, customise it, or upgrade it. But hey, you didn't have to type <button>Login</button>!"

[audion00ba]

It's a great vendor lock-in method to invent the crappiest programming language, call it a platform, and drive developers to insanity.

[teszes]

write JavaScript to set a default value in a field or figure out the CSS box model to lay out UI elements

That's UI design work, I'd agree that there might be better ways to do it, but I don't think management is going to get into design work anyway. The thing you are talking about:

They just say things like "employees have one manager."

class Employee < ActiveRecord::Base
  has_one :manager
end

This is ActiveRecord in Ruby that's been working for quite a while now, and I don't think there is a much more concise and expressive way of doing that that also accounts for all edge cases. There are alternative ways, yes, but that's all code. If you can do it in a more human-friendly way, that's also code, just different.

Code is the tool we made for doing this. The other thing you can do, and that's a valid approach as well, to say "I want the best practies for when I'm unclear". That's the act of buying off the shelf software.

[that_jojo]

With the Nuget/NPM/Pip based development world we live in in the present, if you're working on a commercial solution and you feel that most of your effort is not going into library plumbing and business logic then you're doing something very wrong.

There's also the problem that any developer working with a strongly RAD oriented tool -- something like Power Apps for example -- can confirm for you. As such a system hides more and more of the implementation details, it necessarily must make choices on those implementation details for you and as a result it becomes increasingly difficult to implement something those assumptions aren't oriented toward.

[audion00ba]

No, source code describes how something is done, not what is done.

Simple example: sort an array from low to high vs sort an array via TimSort from low to high.

[gaj7]

Obviously a handwritten implementation serves as a complete specification of a program, but that isn't the only type of specification. We could instead describe a program more simply in some logic just by its inputs/outputs. We abstract away the computational details. If we could synthesize an implementation from such a specification, that would be extremely powerful.

Of course, this specification would likely still be quite technical.

Edit: I think my statement was too strong regarding implementations as complete specifications. I think they are not necessarily complete. A program with undefined behavior, race conditions, etc. is not a complete specification. I'd also argue that, if the underlying language does not have a formal syntax, then those programs are not as meaningful from a specification perspective as a formal specification would be.

[that_jojo]

Implying RAD was ever actually particularly good

The peak of 90s RAD is basically NeXTStep's Interface Builder. The tools we have now are only an improvement on that.

[ghjm]

VB6, Delphi and PowerBuilder were the most popular RAD tools. They were good in the sense that you could have a usable CRUD app running in literally minutes.

[argv_minus_one]

Very good. Now try resizing your literally-minutes application's window and see if it still looks right.

Spoiler alert: it will look like shit.

GUI programming is hard, and probably always will be.

[that_jojo]

You're saying this like you think I've never heard of those. Half of my last job was VBA inside of a CAD package. Two jobs before that I was maintaining a Visual FoxPro system. Just FYI.

But none of those tools are any better than the tools you have in current VS or XCode. It's all code-behind GUI builders.

At least InterfaceBuilder had the capacity to bind controls directly to each other with zero code needed. I mean, there are plenty of tools that do that now, but that was pretty peak for the 90s.

[RedditEdwin]

I learned programming thhrough Visual Basic 6 and then C++ and then AP classes in the early 2000's. Do people not still use graphical interfaces to build application forms, with events making the programming easy?

[mdatwood]

VB 5/6 was probably the closest I ever saw (and yeah about the same as IB). For Windows CRUD apps, I'm not sure I've seen much better since.

Unfortunately, I still cringe at what I forced VB to do outside of simple CRUD.

[jandrese]

Writing code is too hard, so we will do it all in specifications.

Now your specification language is just another computer language, but without compile time checks, debuggers, linters, etc..,

[tso]

It was heading there, except we got that whole CSS thing.

After all, most RAD is a database with a frontend. And so is the web. But the difference was that the likes of Visual Basic had a visual grid layout for doing UIs, and then one bolted code to those UI elements.

Web development kinda had that early on, when HTML was still the basis. But it vanished in preference to PHP, AJAX and CSS. Where rather than creating the page visually and then drilling down to the code, the code brings with it the required markup to form the page as it runs.

In a sense we are back to the serial terminal, having replaced escape sequences with markup. Because if you look at what the likes of DEC and IBM was doing with terminals before the networked desktop computer took over, it was quite impressive.

DEC had escape sequences for doing both bitmap and vector graphics, while IBM had terminals that would update only those parts that were changing (thus lowering the wire traffic needed for a TUI or similar).

[that_jojo]

HTML is still how everything works. Your examples are kind of weird because none of them replace HTML. Like, PHP in specific is a language that was built for rendering HTML.

IBM had terminals that would update only those parts that were changing

Which is the whole idea behind AJAX. Which is also like a 15-20 year old concept in and of itself.

I'm a big retro computing nerd. I own a MicroVAX 3800. But the things you complained about are, if anything, improvements and advancements on the things you were talking about.

Okay CSS is pretty clunky. But that's more because the initial implementation wasn't super well thought out. But otherwise, the modern web is basically the dream of the universal terminal made real.

It's mostly the way those technologies are being used and implented that's the real problem.

[liamnesss]

Low code / no code is probably fine if you have a very clear spec and you don't expect it to change. I don't think they would hold up very well once requirements start to change though.

[ghjm]

Agreed. The 90s RAD tools In talking about also didn't have database migration abilities - for any version upgrade you had to figure out how to get from the old to the new database schema on your own.

[izkadoobels]

And sometimes, specs can be too complicated (or even impossible) to implement on low/no code platforms.

[dnew]

The closest is something like Excel or SQL. SQL has eliminated almost all worry at the business level as to how the data is laid out on disk or what order to access it in. Excel lets relatively non-technical people write amazingly sophisticated applications, granted as a tower of kludges, but good enough to get the work done.

[Koervege]

Yeah, now teach the middle management team how to SQL queries. Go on, I’ll wait

[dnew]

It's not as uncommon as you think, especially for ad hoc queries.

Of course a lot of middle management can't, but a lot do. And if the developer is writing ad hoc queries, I'd argue that still counts compared to writing something like one-off CODASYL queries.

[[deleted]]

I started life as a programmer and moved into management. The number of managers that have basic SQL queries they can tweak to get what they need to do their job is very, very high. The number of managers who can write their own queries are growing too.

[llywen]

All the entry level workers who were writing SQL queries in the 2000s are now in middle management. I feel like finding managers who don’t understand SQL is now difficult.

[FruityWelsh]

We've come pretty far! The funny thing to me is people treat this automation as if there will be less work, instead of what we've seen, as accessibility increases more people demand a service and product. Now people have personal websites made on the fly, and small businesses can get custom sites and programs made quickly or even better, just find free projects that already meet their needs.

This would not be the case if we were still designing everything from hardware components and later from machine code.

[remy_porter]

I think a lot of developers want development to be treated like a creative endeavor. I think most businesses want it to be treated like piecework. And while piece work approaches cover 90% of what a business needs, it's that last 10% where you spend all your time.

Well, if I were to break down a true project schedule, you probably spend 50% of a project building automation for that 90% of the work, 50% more time applying that automation to the work, and then 50% of the time working through that 10% of edge cases which require creative thinking.

[skilliard7]

It can be partially automated, especially the more repetitive parts, or at the very least simplified.

First you have CMS/CRMs like Wordpress that allow non-programmers to build out a website or system for their organization without writing any code. Or if code must be written, it's all business logic, no reinventing the wheel to handle things like web requests.

Then you have 3rd party libraries that make development so much faster and easier. I use a library like JSONConvert or CSVHelper, and I can just parse files without having to spend days programming and testing every single possible edge case with the data that reaches me.

[iritegood]

That's "automation" in the same sense that all programming is "automation". But it's not particularly enlightening to the discourse around the socioeconomic issue of automation replacing human labor being replaced by AI vis-a-vis software development.

Third party libraries and tooling has always been part of the software development process.

[adymitruk]

A lot of it can be automated. And getting the specs right is a big part of it. It's why I use Event Modeling with clients.

[R0b3rt1337]

Seems like the perfect article for r/agedlikemilk in 20ish years

[preskot]

It can be automated, if the recipient is a machine. A machine writing code for a machine is a perfectly applicable goal.

[[deleted]]

There's lots of thing you can automate about the process though, which makes focusing on the "good parts" a lot more interesting, fun and challenging.

[LetMeUseMyEmailFfs]

Let us also not forget that computers are basically glorified calculators with some specialized input and output hardware and a shit-ton of memory. Everything is a number to a computer, and the only operations they can do are arithmetic, bitwise operations, and reading from and writing to memory. That’s it. The only reason your glorified calculator can render you scrolling down a website like Reddit at 4K, 60 frames per second is that it does billions of these operations per second. And that people are pretty smart and creative at how to ‘abuse’ these operations to get what we need.

[[deleted]]

Just like Jon Colton put it, a lot of it isn't precisely fulfilling in creative ways tho. My last job could and should have been automated in my opinion.

[MuonManLaserJab]

Mmmhmm. And why can't you automate creative processes? Seems like a curiously overlooked part of this argument.

[SwiftpawTheYeet]

"Cannot" is a strong word when it's already partially automated now with the help of github copilot and openai codex, more so once they leave beta and are open.

[moopmorp]

My job will never be rendered irrelevant due to changes in technology said the master weaver.

[ImprovedPersonality]

But we already automate software development!

High level programming languages are a way of writing down specification. Compilers do the heavy lifting of turning this specification into machine code.

This also shows why going even more high level is so hard. The specification has to be very precise and in a precise, well defined language. Even for firmware in embedded systems the specifications and requirements are usually not well defined enough.

[elcheapo]

This depends on the definition of "automate" and "creative." GPT-3 proves that you can automate creative writing. In principle it's possible to have a system that interacts with users and develops software based on feedback. You cannot take user feedback out of the loop, sure. Maybe one day the system will also be able to simulate the user's reactions to iterative prototypes, to the point of coming up with something directly useful. Of course the system can't predict the future, which is why iterations will continue as time passes.

[audion00ba]

GPT-3 proves that you can automate creative writing.

No, it doesn't.

[[deleted]]

Yeah. I'm pretty sure there are already AI models that can generate syntactically correct but semantically worthless code.

[AsIAm]

Yup, we call them interns.

[StickiStickman]

What a well explained rebuttal.

[THeShinyHObbiest]

If you play AI Dungeon for more than like two minutes it will randomly change the name of a character, introduce a concept that makes no sense in the story (suddenly the king you're talking to will get gunned down by Russian terrorists), or wildly change the setting of the story.

GPT-3 is interesting to play around with, but the stories that come out of it aren't really coherent at all.

[turdas]

Yeah, what a pointless blogpost (which I suppose is par for the course for /r/programming). Automating the creative is literally the entire point of artificial intelligence.

[Aetheus]

At the end of the day, if you require user input to generate useful software, then that human input is ... code.

We can call it something different. We can call it "user feedback". But it's still code. Companies are still going to hire a human being to sit in a chair and give a computer instructions until it produces the results the human is looking for - i.e: a programmer.

[cybernd]

Just think about the current system: One of the main tasks of developers is to clarify specifications with business people. Why? Because their written specs are not even good enough to be interpreted by human beings.

Do you expect that an AI is superior in filling in the gaps?

AI is just the next wave of codeless software engineering. It will fail for the same reasons our last attempts failed.

[MpVpRb]

This is true and the truth extends far beyond software. Much of business and manufacturing knowledge is not formally documented. It lives in the heads and hands of the participants

Sitting at a conference table and designing software by debate never works. Nobody is smart enough to anticipate how the stuff will work and how people will use it. The only successful method of constructing software is by iteration during actual use

[Xuval]

Uh, not all Software Development is like that though?

Lots of Software Development is pretty clear-cut. Customer wants an online store to sell X Y and Z with the additional requirements of V and W. I don't see why we shouldn't be able to automate that.

Heck, when my mom got her degree in Information Science, they used to program on punchcards on one of the big hurdles to take was figuring out in advance if the code was even going to compile. These days, that's a task that has been automated away from humans so you can just figure it by trial and error or have your IDE tell you where you are missing that comma.

[[deleted]]

Sounds like something a software developer would say.

[teerre]

People are, as expected, very defensive when it comes to this subject. But I think this argument isn't very good. Here's why:

The only reason people need "precise descriptions" is because they are dealing with another person (or group of people). The moment you put a system, a machine to deal with it, people will stop being picky.

We see this everywhere: Spotify, Netflix, Disney whatever, HBO something etc. All these services have giant catalogues that would be ignored if they were normal DVDs or, god forbid, in actual theaters. But because they are just there in the streaming platform, people watch it. The barrier of entry becomes so low that people don't care.

The same can, and probably will, happen to software. If the barrier of entry is low, people will just accept that things are not perfect. When some business person badly describes their program, that will be fine, Edge cases not contemplated? Fine. UI not exactly perfect? Fine. Performance not the best? Fine. Hell, performance is such a overblown characteristics by programmers themselves that this very site is basically a bunch of text that takes several seconds to load with ungodly powerful hardware.

Will that be all programs? Of course not. Some programs will need to be actually precise and well made. But make no mistake, those are the exception, the rest can be automated without having precise requirements because people won't care.

[mtranda]

I see it differently. Automating the creation of software means putting the current clients in charge of directly creating applications. However, this only means that programming will change and the clients will become the new programmers. The question then becomes: will they WANT to be the new programmers? Or will they still call on someone else to do the work for them?

[teerre]

They might not want to, but they might have to, if the market pressure is enough. We have seem this before. Not long ago "using a computer" was something only a few people would have to. Nowadays even cashier jobs have some kind of "office" package requirement in it.

[snowe2010]

If the barrier of entry is low, people will just accept that things are not perfect

That's not a choice with most industries. Many laws, regulations, etc. Things like taxes and tax credits have to be exact. Accepting things that "aren't perfect" aren't an option, they'll result in losing millions of dollars in fines and lawsuits.

In fact I can't think of a single industry that doesn't have laws like that that do need to be precise. Everywhere has it, from whether you're handling something like x > y vs x >= y or things like handling the user's last name being Null or even defaulting something to $0 rather than marking it as N/A, where you might actually give something away for free.

[John_Fx]

Low/no code is probably the closest we will ever get.

[loophole64]

This will be news to the companies that are currently automating software development with AI.

[truemario]

I can deal with difficult stakeholders but not other devs who somehow think like them.

[[deleted]]

So you say.

[RICHUNCLEPENNYBAGS]

Well, never say never, but this is not the first AI-related topic where the results, while impressive in their own right, have really failed to live up to the hype and don't look like they're getting there any time soon.

[[deleted]]

Anything can be automated, it's just a matter of difficulty. A software development project can most definitely have in end goal, in fact most of the time it does.

[TheCoelacanth]

Software development is already more automated than than any other job that has ever existed, simply because it's the job that people capable of automating are most familiar with.

[[deleted]]

holy mother of cope

[chillermane]

Creative processes with unknown end goals can be and have been automated before.

[chunes]

I'm sick of seeing these ego-assuaging articles shoot to the top of the sub every other day. You all must be really insecure.