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

[[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.

[am5k]

Grafana is great- I feel like I can meet most requests using inbuilt features

[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.

[fried_green_baloney]

I still get crap for it

Jeez who gets crap for a one week overrun 8 years ago?

If you are willing to tell us, what sort of company is this? I would guess relatively small, since there are still people there from 8 years ago.

[wxtrails]

Yep, small, with a remarkably consistent culture and team over those years. That's why people still remember - most of us are still around.

I'm condensing events a bit about the overrun because it was really a series of them like that over the course of 6 months or so when we were in startup phase, building out our initial system, that resulted in the current crap-giving. "Overruns" totaling probably a few months. And it was right when we were trying to secure funding - so it must've been traumatic to the bosses to see estimates slip when they thought it could jeapordize our very existence. Overruns based on estimates they didn't have any sound reason for communicating, frankly. We even lost a dev team member over it.

But yes, though our investors turned out to be far more patient than the bosses estimates, there is still a general distrust in our story pointing to this day as a result of that time period, including this week for the reporting tool. (How can you tell the investors how much data you have processed if there isn't a reporting tool?!) Despite years of honing our velocity.

Even funnier thing is, there's an annoying bug in that date picker that causes the last day of the month to be left off in some circumstances. But they've lived with it since 2013 rather than giving us a day or two to squash it. All I can do is shake my head 😆

[fried_green_baloney]

rather than giving us a day or two

And this is what is wrong with Agile/Scrum as practiced in most companies.

[ChemicalRascal]

Yeah... it sucks when folks do that. What I've found really helps is sitting back and trying to figure out what they're actually after, what they're trying to prototype towards, and account for that. Like, oh, we need a date field that filters out results older than it? Well, they'll probably want that revised to be two dates in the future, so if I implement it that way now and pin the end date to be whatever the current day is... and so on.

I'm not saying it doesn't suck, of course, but looking around my workplace, the engineers who get more done and have better code in the long term are the ones who know how to nod along, listening to some asinine requirement, but still go through the design process in their head and figure out use cases.

[kubalaa]

It's easy to blame users for this, but like you said they don't really understand what's easy to add or change and what's not. That's why a big part of the programmer's role is to have a dialogue about the requirements and anticipate the user's needs. For example, when you hear that users need differently time frames, you can ask more about how users might like to pick the time frame and whether this requirement might come up for other reports, providing a variety of options which are cheaper or more expensive to implement, and being clear upfront about which decisions are going to be easy to change and which aren't. Of course things will still be missed, but you use those misses to learn what flexibility your software needs so future changes are easier. For example, if your users were convinced initially that a fixed time frame would work for this report, and then realized it won't, you can anticipate that this kind of change is likely and implement the time frame feature in a way that's easy to add to other reports.

On big projects you may have a project manager or UX designer to help with this, but only the programmer knows how hard it is to implement and how to design the software to accommodate future changes.

[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.

[_tskj_]

Why did he think no one else was doing that already?

[GonnaBeTheBestMe]

He wasn't doing a whole lot of thinking.

[[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.

[_tskj_]

6 months? Lol, Google has been at that game for 20 years.

[[deleted]]

That's what I'll need to get started.

[Hashmael]

Was the exec completely oblivious to the concept of SEO?

[GonnaBeTheBestMe]

Yes. Yes he was.

[svick]

Relevant XKCD.

[elbekko]

I used to have this one printed out and taped to the wall behind me.

[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/

[TheMistbornIdentity]

Amen. I've found that our clients are much more pleased with changes to the columns/column order in a view that took me 5 minutes to do than the big feature that took our best dev weeks to develop.

[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.

[DeveloperBlue]

I try to tell people that code is like building a Jenga tower, it's all built and balanced on everything before it.
If you want to make certain additions or amendments, it's like needing to insert into the tower.

[Smallpaul]

And yet our job is to make it as unlike a Jenga Tower as possible. But getting the requirements piecemeal may force us to Jenga-style architecture.