I don't know if Telegram, Slack, Discord, GitHub Actions, GitLab CI, Jenkins, or Kubernetes will be around (or without massive breaking changes) in 20 years, but email absolutely will be.
> In industrial scale software development, gaining access you are fully entitled to can sometimes take weeks.
4 years in consulting. I've spent the first WEEKS of a project twiddling my thumbs waiting for a laptop, just to spend more weeks waiting on access to source code, tooling, etc.
My friends on the strategy side could start and finish entire projects in that time.
Sometimes it's not about doing nothing but only being allowed to do the same stuff over and over again to do because there is "no budget" to rewrite the codebase to automate the process.
Memories of waiting for months to get access to a MS SQL database and ending up putting an Access database on a network share for multiple user access instead. A horrible, horrible hack solution. But it worked!
I volunteered at an archaeology lab run by the state govt a few months ago.
Knowing I was a data engineer, one of the archaeologists asked me to take a look at the cataloging system he’d cobbled together on his own: a shared-drive Access database with a full-featured CRUD interface that the whole office had been using for years.
I was able to clean up one stray bug he had, and confirm his suspicion that one particular action was running slow because it had to touch multiple files by necessity (he’d rolled his own sharding) — but generally speaking, it was a work of art more effective than anything I could’ve ever come up with. Sometimes the “dirty hacks” are the best solutions.
The best thing you can do in a situation like this is spend an enormous amount of time just documenting everything. Document all of the behaviors.
You will need that before you even start on any kind of a re-implementation
The avoidance of dirty hacks are not because they don’t work. They do and can be pretty X-effective when you’re short on X. But the end result is that when you need to switch away from the hacks, then the interest paid on X can be enormous. If X includes time, it may never be repaid.
Directly related to which is the tech debt that accumulates just by using Access files in a shared folder. Access wasn't intended to work that way. It is documented in many places in Access' manuals to never do that. But it works and most versions of Access don't warn you when they detect you are using a shared folder, so most Access users don't question it.
But I have seen the maintenance burden first hand of solving weird Access lock file problems (if I never have to manually find and delete an .LDB file again, that would be great) and silent corruption issues and more. I've seen the workarounds of auto-backups of the shared folder and then auto-restores of those backups when silly things happen like the .MDB file is not the expected file size.
There's a special "joy" in needing to know the many under-the-hood versions of Access files and seeing apps that consume and/or produce more than one version at a time. That's just to maintain existing "apps", trying to migrate that data to modern databases for new apps is its own "joy" as well.
> A horrible, horrible hack solution. But it worked!
I ended up building an Access app at an enterprise-y company I used to work at because it would have taken years for IT to build it. The app did something super specific and kept needing super specific additional features, and there wasn't anything on the market that met our needs. The Access UI talked to another Access database on a shared network drive. I just found out that it's still being used heavily by several people every day, 17 years later. You pretty much nailed it, Access is hacky, but it works!
I knew a guy who would brag that he used Outlook as his build system 20 years ago. Builds would take 9 to 24 months depending on the complexity of the project. But, as the CTO of a mid-sized software company, it worked for him.
Other than the theme, what's the difference between typing what you want into Slack and maybe getting it can typing it into ChatGPT and maybe getting it?
Long ago, I used to work at some bank, where SVN branch merging was always super painful and instead of solving people problem, there was holy, e-mail based system running on our common dev machines.
After recieving properly formatted email, script was executed to apply git merge between svn branches.
In case of merge issues, the email was sent back with feedback.
If everything was okay, a proper sign-off blessing by one of the technopriests as late check was applied and merge concluded.
As a dev currently working at a company where getting an access request fulfilled can sometimes take weeks, I feel this author's pain.
But it seems like an enormous security hole, even with a codeword "password". The author didn't mention it, but I hope they're using whatever version of their company's E2E email encryption is for these messages.
Yeah, this is textbook "shadow IT" that could easily lead to something going seriously wrong. It's a fun example, but not something to aspire to.
Ultimately the problem is that in a lot of big corps, IT is basically unaccountable for setting things up wrong. Their only KPI is tickets closed, not the quality or success rate of their fixes.
I've always felt that if business types can get over their fetish for trying to measure absolutely everything, we wouldn't have problems like these that stem from poorly thought out KPIs.
They default to tickets closed, uptime, SLA adherence as KPIs because you can't effectively measure "is it set up correctly?" and because the business absolutely must measure everything, they come up with bullshit KPIs so they can have a pretty dashboard and pretend like they're actually managing.
Glad I'm no longer in huge corps, but still an IT manager. Shadow IT is a direct symptom of IT not providing the right tools or having poor processes. But responsibility still lies higher up in the chain. If we weren't forced to quantify all activity, these issues wouldn't exist.
Ticket closing and KPI chasing is alive and well in small companies too. I have a client (less than 100 folks) that has a JIRA reporting process on par (and as bad as) as F500 company.
Seems to geared towards tracking work and increasing accountable behavior.
But then the consultant overseeing it (not me) sent a Claude generated report with some sort of JIRA ticket dump as input. All the tickets closed were in fact not done or not relevant. But they were “closed” in JIRA. Same thing with completed tickets.
Embarrassing work product and embarrassment for the company.
It's been over 20 years, but I used to build batch processing pipelines using SMTP (not Outlook). Biggest "choose your own adventure" aspect is accounting / auditing (making sure you didn't lose batches). I still joke about it as an option; although if somebody took me up on it I'd write up at least a semi-serious proposal.
In the middle are Mule, Rabbit, Kafka, ZMQ.
At the other end is UDP multicast, and I still use that for VM hosts or where I can trust the switch.
I can not believe blogspot is still alive. I just went there and it auto-signed me in via my Google account to "Blogger" where there are some posts from Google's blogspot. The last post was in 2020 https://blogger.googleblog.com/
It should receive a badge of honor because even Google can't kill it! Honestly though, it's pretty damn good for just hosting a blog, surprisingly many options. A bit weird to write in, so I write externally, but pretty fully featured for what I need.
Sure, "docker push" is all fine and well until "after two weeks, [your] coworker still does not have access to the server endpoint that he and [you] would need". And then what? Do you quit your job for fear that someone calls you a hack?
There are so many issues with what you have here… where to start…
You aren’t running tests, unless you put them in the dockerfile which is a bad idea…
You aren’t running security scans. how do you deploy manifest changes? Using Latest as a tag has so many issues.
This is a trivial and niave pipeline I would expect from a junior or intern.
Build pipelines are becoming more complicated because software is more complex. You can still promote ownership of the full pipeline while giving developers control.
Don’t shy away from it, understand it, embrace it. It’s just going to continue getting more complex
Adding steps for code quality scanning, dependency vulnerability analysis and a license scanner certainly makes it look like you actually achieved something in the next performance review, I will give you that.
Totally unrelated, if you need to suffix a k8s deployment with "-deployment" you are a hack, a fraud, an overengineer and someone who should NOT work as software or devops engineer.
Famously so. If you want to remain unmisunderstood, make sure to use sarcasm. Draw a clear line into the shifting sand while cocking a single eyebrow. It's widely appreciated, it's an artform, and the comments are a blast. :)
I don't know if Telegram, Slack, Discord, GitHub Actions, GitLab CI, Jenkins, or Kubernetes will be around (or without massive breaking changes) in 20 years, but email absolutely will be.
TIL that Jenkins was only released in 2011. Feels like it's been around since forever.
If you're like me, in your mind Hudson and Jenkins are the same thing, so maybe you started using "Jenkins" before 2011 when the renaming happened!
2011 was a huge year for tech/devops. I feel like so much of what we do now started right then for some reason.
I think that might be because it was called Hudson before that I believe.
Unless that was a different project altogether?
Same project, rebranded around Oracle. Basically MySQL/MariaDB without the alliteration.
> In industrial scale software development, gaining access you are fully entitled to can sometimes take weeks.
4 years in consulting. I've spent the first WEEKS of a project twiddling my thumbs waiting for a laptop, just to spend more weeks waiting on access to source code, tooling, etc.
My friends on the strategy side could start and finish entire projects in that time.
Your friends on the strategy side are the folks those clients think parachute in, drop a deck and convince execs to do things, and the disappear.
Not necessarily worse, but the stereotype fits! You are, at least, soon doing tangible things.
Accenture? Lol
>When you leave software developers alone for too long, they start developing software
I've gotten so bored at work lately I've been coding for fun again
What job do you have that you get paid to do nothing?
Sometimes it's not about doing nothing but only being allowed to do the same stuff over and over again to do because there is "no budget" to rewrite the codebase to automate the process.
Memories of waiting for months to get access to a MS SQL database and ending up putting an Access database on a network share for multiple user access instead. A horrible, horrible hack solution. But it worked!
I volunteered at an archaeology lab run by the state govt a few months ago.
Knowing I was a data engineer, one of the archaeologists asked me to take a look at the cataloging system he’d cobbled together on his own: a shared-drive Access database with a full-featured CRUD interface that the whole office had been using for years.
I was able to clean up one stray bug he had, and confirm his suspicion that one particular action was running slow because it had to touch multiple files by necessity (he’d rolled his own sharding) — but generally speaking, it was a work of art more effective than anything I could’ve ever come up with. Sometimes the “dirty hacks” are the best solutions.
The best thing you can do in a situation like this is spend an enormous amount of time just documenting everything. Document all of the behaviors. You will need that before you even start on any kind of a re-implementation
The avoidance of dirty hacks are not because they don’t work. They do and can be pretty X-effective when you’re short on X. But the end result is that when you need to switch away from the hacks, then the interest paid on X can be enormous. If X includes time, it may never be repaid.
Directly related to which is the tech debt that accumulates just by using Access files in a shared folder. Access wasn't intended to work that way. It is documented in many places in Access' manuals to never do that. But it works and most versions of Access don't warn you when they detect you are using a shared folder, so most Access users don't question it.
But I have seen the maintenance burden first hand of solving weird Access lock file problems (if I never have to manually find and delete an .LDB file again, that would be great) and silent corruption issues and more. I've seen the workarounds of auto-backups of the shared folder and then auto-restores of those backups when silly things happen like the .MDB file is not the expected file size.
There's a special "joy" in needing to know the many under-the-hood versions of Access files and seeing apps that consume and/or produce more than one version at a time. That's just to maintain existing "apps", trying to migrate that data to modern databases for new apps is its own "joy" as well.
> A horrible, horrible hack solution. But it worked!
I ended up building an Access app at an enterprise-y company I used to work at because it would have taken years for IT to build it. The app did something super specific and kept needing super specific additional features, and there wasn't anything on the market that met our needs. The Access UI talked to another Access database on a shared network drive. I just found out that it's still being used heavily by several people every day, 17 years later. You pretty much nailed it, Access is hacky, but it works!
Edit: grammar
Not intended as an endorsement, but Access / FileMaker / 4D were all great solutions for low-contention, low-user count low / no code CRUD apps.
I knew a guy who would brag that he used Outlook as his build system 20 years ago. Builds would take 9 to 24 months depending on the complexity of the project. But, as the CTO of a mid-sized software company, it worked for him.
CTOs are the original vibe coders.
Other than the theme, what's the difference between typing what you want into Slack and maybe getting it can typing it into ChatGPT and maybe getting it?
> Builds would take 9 to 24 months depending on the complexity of the project.
I might be stupid, are you saying a build would take 9 to 24 months to finish?
They're saying he used Outlook to assign a project to a team.
Yeah, it confused me also
Either its the wrong unit (minutes?) or the wrong definition of "build"?
Maybe the build system was him sending the email to some factory that would encode it into the silicon of a chip and ship the chip back to him.
Long ago, I used to work at some bank, where SVN branch merging was always super painful and instead of solving people problem, there was holy, e-mail based system running on our common dev machines.
After recieving properly formatted email, script was executed to apply git merge between svn branches. In case of merge issues, the email was sent back with feedback. If everything was okay, a proper sign-off blessing by one of the technopriests as late check was applied and merge concluded.
/Mail/Messaging in SMTP, and you have what it is: A message broker and queue. It has durability, retries, everything
SMTP is even a transport for SOAP
It was really fun using filters in Pegasus Mail (no SOAP) to automate mailing lists, PGP key signing with e-mail validation etc.
>Shoddy stuff that has no chance of making its way into production is permissible
That's cute.
As a dev currently working at a company where getting an access request fulfilled can sometimes take weeks, I feel this author's pain.
But it seems like an enormous security hole, even with a codeword "password". The author didn't mention it, but I hope they're using whatever version of their company's E2E email encryption is for these messages.
Yeah, this is textbook "shadow IT" that could easily lead to something going seriously wrong. It's a fun example, but not something to aspire to.
Ultimately the problem is that in a lot of big corps, IT is basically unaccountable for setting things up wrong. Their only KPI is tickets closed, not the quality or success rate of their fixes.
I've always felt that if business types can get over their fetish for trying to measure absolutely everything, we wouldn't have problems like these that stem from poorly thought out KPIs.
They default to tickets closed, uptime, SLA adherence as KPIs because you can't effectively measure "is it set up correctly?" and because the business absolutely must measure everything, they come up with bullshit KPIs so they can have a pretty dashboard and pretend like they're actually managing.
Glad I'm no longer in huge corps, but still an IT manager. Shadow IT is a direct symptom of IT not providing the right tools or having poor processes. But responsibility still lies higher up in the chain. If we weren't forced to quantify all activity, these issues wouldn't exist.
Ticket closing and KPI chasing is alive and well in small companies too. I have a client (less than 100 folks) that has a JIRA reporting process on par (and as bad as) as F500 company.
Seems to geared towards tracking work and increasing accountable behavior.
But then the consultant overseeing it (not me) sent a Claude generated report with some sort of JIRA ticket dump as input. All the tickets closed were in fact not done or not relevant. But they were “closed” in JIRA. Same thing with completed tickets.
Embarrassing work product and embarrassment for the company.
If the author were to pray to the overlord, they might receive the blessings of the holy PGP/GPG order.
It's been over 20 years, but I used to build batch processing pipelines using SMTP (not Outlook). Biggest "choose your own adventure" aspect is accounting / auditing (making sure you didn't lose batches). I still joke about it as an option; although if somebody took me up on it I'd write up at least a semi-serious proposal.
In the middle are Mule, Rabbit, Kafka, ZMQ.
At the other end is UDP multicast, and I still use that for VM hosts or where I can trust the switch.
I can not believe blogspot is still alive. I just went there and it auto-signed me in via my Google account to "Blogger" where there are some posts from Google's blogspot. The last post was in 2020 https://blogger.googleblog.com/
It should receive a badge of honor because even Google can't kill it! Honestly though, it's pretty damn good for just hosting a blog, surprisingly many options. A bit weird to write in, so I write externally, but pretty fully featured for what I need.
Might need to implement this at current project but with Teams
Good. The next step is turning that into an OS. From there, you should be able to take it further and fully support virtualization.
...but why?
To run Doom, what else?
Realest post I've read in a long time
Hacky is as hacky does.
You can use git as a backend for an MTA and come full circle...
This is horrifying.
that guy is a fuckin legend
[dead]
[dead]
[flagged]
Mom, didn't we talk about not posting to hacker news when you're like this?
Thankfully k8s is not overengineered or you’d have pie on your face.
If your build pipeline is anything more than a monkey scratching bits into a spinning disk using a needle, you are a fraud.
> If your build pipeline is anything more than a monkey scratching bits into a spinning disk using a needle, you are a fraud.
Obligatory XKCD cite: https://xkcd.com/378/
No plan survives contact with the enemy.
Sure, "docker push" is all fine and well until "after two weeks, [your] coworker still does not have access to the server endpoint that he and [you] would need". And then what? Do you quit your job for fear that someone calls you a hack?
Wait, my docker registry has no authorization? Uh oh
The executing system provides an authenticated kubectl.
There are so many issues with what you have here… where to start…
You aren’t running tests, unless you put them in the dockerfile which is a bad idea…
You aren’t running security scans. how do you deploy manifest changes? Using Latest as a tag has so many issues.
This is a trivial and niave pipeline I would expect from a junior or intern.
Build pipelines are becoming more complicated because software is more complex. You can still promote ownership of the full pipeline while giving developers control.
Don’t shy away from it, understand it, embrace it. It’s just going to continue getting more complex
Adding steps for code quality scanning, dependency vulnerability analysis and a license scanner certainly makes it look like you actually achieved something in the next performance review, I will give you that.
People don't get sarcarm :/
Totally unrelated, if you need to suffix a k8s deployment with "-deployment" you are a hack, a fraud, an overengineer and someone who should NOT work as software or devops engineer.
> People don't get sarcarm :/
Famously so. If you want to remain unmisunderstood, make sure to use sarcasm. Draw a clear line into the shifting sand while cocking a single eyebrow. It's widely appreciated, it's an artform, and the comments are a blast. :)
If your build pipeline is anything more than a deploy.sh file containing
go build binary
scp binary root@server:/deploymentlocation
you are a hack, a fraud, an overengineer and someone who should NOT work as software or devops engineer.
2 commands -that‘s 33% better than my solution!
Look what “real” devops engineers have demanded respect for. They have played us for absolute fools!
I like [x]copy deployments personally, then you have 1 command =)
I bow!
We had that at my first job where I deployed .war to a remote production tomcat directly from eclipse with one tool button click.
Zero lines of code even, depending on definition.
Yes, all development is just backend web development and CRUD apps.
If you're doing anything else, are you really an engineer?
bwahaha.
Uses kubernetes, blames others for over engineering. Are we living in a parody? Oh wait…
For a moment there I thought this was the parody llm HN site.
Please give me the link
https://news.ysimulator.run/
https://news.ycombinator.com/item?id=46036908
yeah sure....