Software engineering research questions
neverworkintheory.org
neverworkintheory.org
My most important question regarding software engineering would probably be something like: how well are resources allocated and could we do a better job? Consider how many brilliant and outstanding people go work on some useless software at a big adtech company rather than helping to improve the world. The greatest tragedy of our time.
My naïveté inclines me to think that there are more brilliant people working on world-improvement project than the opposite.
Facebook was created to connect people and ended up facilitating genocide.
Breakthrough in private health-improving tech can bring unfathomed gap between rich and poor.
We can only speculate where new developments such as AI will lead us.
The 1990s Rwandan genocide was coordinated by 1-way radio.
Throwing out the baby with the bath water here. How many lost friendships were recovered through FB? In my network of immigrants and refugees: countless.
>Breakthrough in private health-improving tech can bring unfathomed gap between rich and poor.
This is absurd. Why is the gap more important than the absolute level of the poor? All medical tech began as expensive and only for the rich.
In the case of Facebook, the bath is toxic, we should remove the baby from the bathwater, toss out the bathwater, and then figure out what's going on (maybe we can just refresh the bath, maybe we need to figure out a regulatory framework for designing baths).
Manhattan project?
There's a lot of people on HN who can relate to this experience. That's where our intuition that there's a lot of people working on stuff that is useless to 99% of people, but will help a small elite get richer, comes from. It's literally what we do for a living, or used to.
Look at the top companies on the S&P 500 and where most of their revenue comes from. How much are these activities really improving the world?
If only the internet had had a built in mechanism for automatically micropaying for content as part of your internet bill (like flip phone ringtones used to work in the aughts, or how Minitel supposedly worked in France in the 1980s) adtech would never have happened and we would have a totally different internet. Instead we have this tragedy of the commons where the greatest minds money could buy are figuring out how to get people to waste more of their precious minutes on earth clicking on more cat videos so candy companies will pay for the server bill.
That doesn't have any relevance to a critique of capitalism. They both have problems. Also, even if we compare them on "environmentalism", that's only one criteria.
Pedantically, you are correct. But pragmatically, the people who write "capitalism is bad because of X" are usually interested in replacing it with leftism.
> only one criteria
Your post would be more interesting if you pointed out one criteria where Marxism is better.
These alleged people aren't here though. This is the definition of strawman arguing. Sorry, but you need to engage with the actual positions of the people who you are actually responding to, not the positions of some other people you once met somewhere else but that remind you of us. That kind of discussion is a total waste of time.
Marx is one of those people. His written words paraphrased here by you.
This sounds like looking for a fight that has been fought thousands of times before rather than looking to learn something interesting though.
To me a more interesting question would be, if we steel man the public conception of the problems of capitalism, and we accept that the public conception of communism is problematic to implement to say the least, what remains? How can we move forward without endlessly getting stuck in the same tired argument about communism? How can intelligent people discuss solutions to these issues? What are our alternatives?
Don't comment on Marx if all you know is "lol communism didn't work in russia". That's a borderline non sequitur that just reveals you don't know what Marx said at all. It's like British people meeting Mormons and saying "Oh you're a real mormon? What like from South Park?" You don't have to read Marx in the original, just spend half an hour on a Wikipedia or cliffsnotes summary at least beforehand. Maybe do the same for Smith and Ricardo, too, so you can have a good overview.
It didn't work anywhere else, either, and it's been tried thousands of times. Note I did not say "Soviet Union".
Do you also refuse to learn basic physics because Isaac Newton was imperfect and despite coming up with some great physical laws, also believed some nonsense about alchemy that later was shown to be nonsense?
Do you bring up the craziness of alchemy every time newtonian mechanics comes up, and refuse to believe in momentum, mass, and kinetic energy?
Having to argue about this crap every time Marx comes up is tiring and intellectually ineffecient.
At this point I wish we could blame just the smart things Marx said on someone else like say, Mark Twain, just so the adults in the room can discuss the workings, benefits, and problems of capitalism without constantly getting interrupted by irrelevant low-effort arguing.
What I want is a good faith argument for something that works as a solution for Marx stated problem. What can we propose? What can we learn?
My impression was that the maximization target is the building of the best possible world that can be imagined _for the owners of capital, in proportion_.
A farm in any time period is built to maximize the success, convenience, and happiness of the humans who own and operate the farm, right? Not the happiness or convenience of the chickens or pigs. If making the livestock happier and better fed helps the farm's goals, it will be done, and if not, not.
This frame of reference helps explain a lot more about the world than imagining that anyone with any relevance actually cares about the world being good for most of the people in it. Most of us are just livestock, a means to an end for the proprietors.
Considering how well central planning has worked historically, allow me to approach this issue with a bit of skepticism.
For example, during the gas crisis around 1980, the Dept of Energy was empowered to determine the gas allocation for every station in the country. The allocation was based on the previous year's markets. This was well-intentioned, but it did not take into account the fact that markets change constantly. The result was stations with gluts and stations with shortages.
Not for a second. Ubuntu is a repackaged Debian and both Debian and Wikipedia are volunteer-driven.
They are not for sale and therefore unrelated to "market forces".
Besides, tax-funded government-managed research gave us telephone networks, semiconductors, computers, GSM, GPS, fiber optic, satellites, Internet, airplanes. Is that enough?
Attributing particular achievements to one or the other is impossible.
> tax-funded government-managed research
Um, read up on the history of the 1903 Wright Flyer. It was not government managed research. The government project, Langley's airplane, fell into the Potomac like a sack of wet cement (and cost 20 times as much).
Computer networks grew out of telegraphy networks, which were privately funded.
Semiconductors came from Bell Labs, a private company.
I don't think we can pin either system as being more virtuous or not, we just seem to have more hisotry of centralized corrupt power at this point since thats been the global state of affairs and humanity just started experimenting with alternatives relatively recently that the verdict is still out on. Both approaches have their ups and downs and both approaches need governance to keep their power in check. Which has the higher corruption rate? Who knows.
Centralized systems seem to have a quicker escalation from start to corruption but they also tend to destablize quickly. Meanwhile, decentralized systems seem to still reach a sort of steady state of corruption at some point and seem to be more difficult to destablize (fix) because it's easier to argue the state of the system evolved "fairly" in some way that we can't just fix.
Child labor used to be necessary for subsistence farming as otherwise everyone would starve. Improving productivity due to free markets ended that, and made it possible for children to not need to work.
Have you ever thought about children in your workplace? In most I'm aware of, they'd be useless and even counterproductive. Child labor is only for the most menial of tasks, and those have long been automated.
Market forces created an economy which made everyone rich including the government which could then afford to spend a very large amount of money on one project, which also wouldn't have worked without the skills people acquired and the products that were created in the market economy.
Check your privilege.
I think the real dichotomy is societal (long-term) value vs. individual (short-term) value. The latter has led to an industry destroying the planet, "social media" actively promoting hatred etc.
How to implement socially valuable objectives instead of those destroying the basis of human life and atomizing society is a difficult political question. Central planning is probably not the answer, but that does not mean we should just give up.
You could even make an argument that some of the current US problems are caused by central planning, for example in the form of tax code based incentives or major spending packages
Another separate (but related in some ways) argument is that many companies and individuals can externalize their costs, and this distorts markets
That's not a solution, it's a misdirection from the problem
I've had conversations with young people nearing graduation about their career choices. Often it revolved around compensation levels at various tech companies. I'd ask them if they really wanted to dedicate their life to finding better ways to serve advertisements, or do they want to do something great?
However I still think the situation is a bit worse. The tradeoffs in the models you mention are well understood. The equivalent in SE would be something like "should we use python or go", but it's very unclear that we can definitively state which use cases are better for which. There is simply no evidence, the plural of "anecdote" isn't "data".
This is such an important question and it's just the tip of the iceberg of a very deep problem that is rotting our software systems. We are absolutely pathetic at dealing with complexity and we actually enjoy complexity. We don't tackle questions such as 23. ANYWHERE near as seriously as we should.
Developers overestimate their mental bandwidth which leads them to pompously build over-complicated tech stacks despite only having archaic tools to mitigate and navigate their complexity.
Companies don't need to hire more devs to deal with their complex software systems, they need better tools to navigate their software systems. But because companies don't truly value their money and devs don't truly value their time, we end up in the situation we are in now. We should have hundreds of companies investing on initiatives akin to Moldable Development[1], instead they play the following bingo: 1) let's just hire more devs and hope to land on a 10xer 2) let's build our own framework
Additionally, we overvalue specialization. By overloading developer brains with complex tech stacks, we encourage a culture of specialized profiles who find solace in trivia. Doing so, we limit cross-pollination and stifle true innovation. This attitude is actively killing-off thousands of valuable ideas. Every second, there's a coder out there who thinks of something wild, which requires very specific tools from different fields and finds out that the people who built such tools couldn't be bothered making them accessible under a sensible time-budget to people outside of their niche/ivory tower. So the dev either drops the idea or gets sucked up into a niche.
This is tragic, but hey look! We have a new (totally not low-hanging fruit that could be predicted 10 years ago) Generative Model, WOW! "What a time to be alive"!
Spot on. Most engineers don't (and can't) demand a working understanding of the systems they build, and are perfectly happy reverse engineering even their own creations (although we rarely admit so bluntly that this is the case). So, we're primarily a trial and error species, not architects. Alchemists, perhaps?
Tests, which is the only way any moderately sized software holds together, is just a way of automating the trial-and-error process from development. It even kinda works, but is limited by (among other things) the imagination of the test author, which frequently happens to be the business logic author.
There is no scientifically correct answer to what often are not objective questions, you will quickly find out that almost everyone will weigh the questions that the article asks very differently, for often legitimate reasons.
Electronic circuits are also human artifacts, but there objectively valid principles and practices for developing those. Of course there are also opinions and subjectivity on some characteristics that generally don't matter to the actual functionality, but that seems far from where software development currently is.
1. Under what circumstances is a monorepo beneficial as opposed to multiple smaller repos and what are the determining factors? (Team size, codebase size, tooling, software coupling, project velocity, .... etc?)
2. Under what circumstances are different system architectures better, and what are all the different factors that influence this? (eg microservices, 3-tier, one big blob of code, ... etc)
3. Can we empirically measure or determine whether a language, framework, library etc is the right choice for a given situation and how might we do that? Is it possible to formulate rules to inform good decisions here or is it always going to be a matter of judgement?
4. How do different styles of working (Pair programming, scrum, TDD etc) affect team productivity, code quality, developer happiness, project velocity etc? What are the factors that make one preferable over another in a given situation?
5. What's the right team size for a given project?
6. What's the best way to discover and communicate software requirements?
...
I could go on. But in other engineering disciplines, a lot of the analogous things are solved problems rather than being topics for heated debate.
What's "MAGMA"?
Basically you pick the initialism and then you choose companies that plausibly could fit into it.
[1] Edit: errrr, that doesn't quite work does it. Meta, Amazon, Google, Microsoft, Apple lets say.
That being said, I think that Meta is evil and should not be promoted in any way - so we might go for a version without it, for example MAGA! Oh, wait... :P
The old bad days of shrink-wrapped software involved installing in environments we could not control. Tbe direct costs of writing an installer and testing (the larger effort) install, upgrade, uninstall, recovering from partial installs, etc. were nothing compared to the costs of dealing with all the weirdness that could exist on a customer's machine.
We're doing things like blue/green deploys and CD - things not remotely possible in that other world. And we're hooking up all kinds of monitoring and observability tooling that . . . even if we could have shipped that to customers on physical media, we'd be unable to harvest data from in those old times.
I think we're spending a lot less engineering time and getting a bigger bang for the effort.
I worry, though, that because software engineering has the shared professional memory of a goldfish that can always swim to an unvisited side of its bowl, we'll somehow try to repeat that pattern we've overcome.
I worry that software engineering is building a lot of tech stacks that need active maintenance and can't really go into a classical long term support style use.
Also by shipping a standard webview and js app, if you want to go that route. But there were plenty of cross platform solutions before that, most notably java.
Of course you know all that, guess I'm just trying to remind us that desktop deployment wasn't that unsolved and still isn't.
https://www.microsoftpressstore.com/store/code-complete-9780...
If you have rotation in the team it is a lot easier to get new people write new code than learn old ways - especially when original authors are all gone.
If you have stable team, as long as knowledge is there and module fits style of the team I think rewrite will not be needed unless someone wants to shove some not fitting requirements there, which would be better handled by just making separate module.
> Do doctest-style tests (i.e., tests embedded directly in the code being tested) have any impact long-term usability or maintainability compared to putting tests in separate files?
> Has anyone analyzed videos of coding clubs for children or teens to see if girls are treated differently than boys by instructors and by their peers?
> Has anyone ever studied students from the first year to the final year of their program to see what tools they actually start using when. In particular, when (if ever) do they start to use more advanced features of their IDE (e.g., “rename variable in scope”)?
This is an awesome list of questions and it's incredibly thoughtful that you documented and shared it with us.
It reminds me of Hitchhikers Guide where they know the answer but need the question. So many answers are out there floating around that we are often trying to force into certain frames for various motivations.
Having questions that get us thinking, recognizing how unclear things are in current state, this feels like such a powerful thing to share.
Apologies for the diatribe, very much appreciated.
Taking a step back I wonder: if there did emerge clear, incontrovertible evidence that doing X led to better outcomes, how many teams would actually adopt it?
And how many would dismiss those findings regardless?
In these modern times I suspect we'd see a far higher rejection rate than 10-years-ago me would've anticipated.
But yes, we do take too much on trust.