Ask HN: What is the single top-priority software engineering problem?
If you have unlimited time and/or resources, what single software engineering problem would you address? I'm not talking about "Peace on Earth"-type problems, but rather real world practical problems facing software engineering that could be actually solved if you could pay an rationally large team of serious hackers a rationally large amount of money for a rationally long period of time. Another way of asking this is: What's the most important piece of technical debt across software engineering, that could practically be solved if we put enough energy into it?
363 comments
[ 1.6 ms ] story [ 414 ms ] threadI think collectively we need more thought on how to design declarative systems that are tangible inspectable debuggable in the same way following procedural code is
[0] https://twitter.com/jeanqasaur
User interface responsiveness.
The Web being based on standards that leak users' data left and right.
Touch capabilities can be a nice addition to many types of desktop productivity software without detracting from what's already there. Companies reworking desktop applications to look and feel like mobile apps (with all of the related pros and cons) is what causes productivity to suffer rather than anything inherent in the paradigm.
This is basically what I mean by mixing paradigms, and it's getting more and more common in operating systems as well, with Windows as clear leader.
As for touch input, I personally think it's of little use on the desktop. I've already got a mouse, which when properly configured is a pixel-precision input device. I simply cannot do the things I do with a mouse on a touchpad, let alone a touchscreen.
There are several other crimes as well, big and small, mainly in Windows but also on Linux/BSD (especially in Gnome, where the worst decisions made seem to perpetuate into other FOSS DE:s). Apple is still keeping things relatively sane, even though they've slipped somewhat of late.
One example: lots of software devs have no training and/or interest in security, and employers have no way to vet that.
Another: there is no way for users to trust SaaS security. I have no idea whether (as a random example) Atlassian has a great security culture or a terrible one. We just trust people who seem trustworthy, usually due to their polished marketing.
- Most people use their own computers with high-quality local hardware, not a shared workstation, a public terminal, or a dial-up / serial line. So "store a secret on the client" becomes viable. (One of the biggest quiet successes in security, in my opinion, has been that everyone uses SSH as standard practice instead of telnet, and most of them use SSH keys or similar instead of passwords. It is significantly better to authenticate with unencrypted SSH keys on a laptop you keep in your bag or house than with a password.)
- Most people carry a phone around with them, and you can authenticate them by whether they have the phone.
- You can get a tiny USB device that does serious cryptography to authenticate you (and authenticate the site you're connecting to) for about $10. You can get two of them and put one next to wherever you keep your birth certificate, in case you lose the first.
All of these are technical wins worth celebrating, and now we're at the point where the people problem is not so much convincing the CEO to use a better password as convincing systems to use one of the above methods instead of using passwords at all.
I am working on this problem. Let me know if you are interested, I would like to hear your opinion. My Keybase is in my profile or I email you.
But I'm not an OS expert, maybe it is possible.
I suppose if you were gonzo about it you could format the first track with sectors all numbered zero, and eliminate rotational latency. You'd save 80 ms (on average) that way.
Didn't seem worthwhile at the time :-)
But my Chromecast takes a very long time to start, modern TVs, Blurays, mobile apps etc.
10ms response is a bit on the fast side. Aside from pros doing sports or music, we (humans) don’t register most kinds responses that fast. Plus a 60hz display is 16ms anyway. These days browsers, editors, and OSes really do usually try to meet this goal for the most common workflows, though there are plenty of demonstrable exceptions. It’s a good goal, I agree with it, but maybe 100ms would be a more reasonable worst-case response time?
But for worst case in general, not bad.
At least get typeahead working properly again. Various places have borken this, especially Facebook, but back on vt3270 systems experienced operators could just hammer a bunch of data into forms as fast as they could type. Can't usually do that with web apps.
I've used a Tempest arcade machine with near-zero latency, and it was a very weird and pleasant experience.
This problem is best solved with an effective, reliable sleep/wake mechanism, not a fast boot mechanism.
That seems nuts to me. I'm not sure how you fix it without being Amazon/Google. People moan about Terraform too before that gets mentioned.
Nothing radical. Just a managed service provider that would build and maintain the CI/CD pipeline for them.
I'd really like to understand more about what the pain points are here. In contrast to your experience I spend almost no time deploying code. We commit, tests run, we click a button and the deployment is updated in our kubernetes cluster. We did have to put a fair bit of work into our gitlab pipelines and the tooling that patches config into our kubernetes manifests and depoys them to the right place (let's say 2 person months all-in), but the payoff in the end was pretty significant. We're a fairly small company so if we could afford to put the time in to build the foundation for painless deployment I wonder what prevents larger orgs from doing this work? Is it access to the right skills? Difficulty prioritizing non-revenue tasks?
The last project I worked on was deployed to two different environments (double the headache in itself). One side required AWS CloudFormation (requirement imposed on us for that side to be serverless) which we were new to, so we brought in three different specialists one after another. None of whom could really help other than to tell us it was messy and confirm that we were on the right track.
There was a time when I'd just drop a jar and an init script on a linux box for an MVP, now I'm looking up what the yaml should be for sticking a lambda in a VPC, or adding security groups to EC2 instances or whitelisting CloudFront access IP addresses. And redeploys involving CloudFront are slooow. I think that project must have used a dozen AWS services and a few thousand lines of CloudFormation - for deploying perhaps half that many lines of code.
Honestly most of the effort was not in the gitlab pipelines. We found those facilities easy enough to understand and implement. Most of the work went into the tooling layer between gitlab and our runtime environment. My email is in my profile if you'd like to reach out with more specific questions.
We've still got a lot to build, but the goal is zero config deployment for any app/service.
I want to be able to plug APIs together, process user input, have persistence and identity, without writing so much boilerplate.
Think about what Excel did to productivity, and multiply that by 3x or more. That's what no code could do as the 60% solution for a 200x larger labor pool (more like 80% solution for anyone who can't access engineering talent). It would also make its creators obscenely rich. With the amount of processing power that we have, the time for no code is now.
By the way, there's a large chance that Big Tech incumbents won't be the ones to create the no-code holy grail. They have institutional handcuffs that will make that difficult.
How? If you want a language to be adopted and become standard, it would have to be free and open-source. You don't get "obscenely" rich from that.
This is a good example of those problems that could relatively easily be solved with a proper public-goods funding mechanism, but very difficultly without.
Remember, non-engineers are more sensitive to ease of use. They aren’t as fickle as engineers are with dev tools. That’s why they pay money for Microsoft Word and stick with it even though there are many free competitors. They’re accustomed to Microsoft Word, their friends use Microsoft Word, and the software is always marginally better because outsized profits are reinvested into the software.
Additionally, if the above is not enough to make one obscenely wealthy, consider this: it is not pre-ordained that no-code would be as open as a programming language like Python. In fact, it might be better for the users if no-code is a platform rather than an open-source framework (I don’t believe that, but maybe). Obviously, platforms can charge rents as the intermediary between end-users and suppliers of services on the platform. That will make you fabulously wealthy, assuming widespread adoption.
So, if there is a lack of:
- profit potential from ancillary services, and
- funding from users, suppliers, and patrons
- or, in any case, if the no-code would be fundamentally worse with open source
then a for-profit platform is the way to go. Personally, I believe that the open source + ancillary services route will result in a better ecosystem. Nonetheless, it’s worth investigating which of those three clauses are true (if any) and why, because that will have big implications for the no-code project.
Abstracting away infrastructure just means it will become increasingly centralized as a commodity and less likely/harder to create independent services.
Look at n2n or userbase, they’re open source and can be self hosted.
Other nocode tools can follow suit, and can be federated.
I agree with the other comment that this can have the same effect as the one Excel had during the past decades (there are companies running completely on Excel).
At the moment though, the tools feel too limited.
So by default the majority are looking for hosted services, otherwise they'd just build their own stack. For anything other than some organization building a bunch of applications, that same Nocode Dev has no need to ever migrate so long as some major service provider is doing it for them.
Google died when they stopped being well informed librarians and started being aggressive salespeople. It's time for a new search engine to step in specifically catered to the curious.
Being able to update libraries, tools etc. automatically and without friction. Right now upgrading is so tedious, error prone and painful that most places just keep using ancient versions that are not only lacking bug fixes and newer features but are a huge attack surface.
It's a human coordination and cooperation problem on a global scale.
But, yes, without users it is easier to create software.
Completely pointless, but much easier.
Offer different versions.
Sandbox programs at the OS level to mitigate old (or new) vulns.
Not trivial but maybe automated by some meta-meta-build tool?
I could start a new project with Spring Boot and Ember.js, provision a Debian box with Postgres and nginx, and deploy all of it within an hour because I know these tools. But I too paid the learning price my first go round.