Live data from Hacker News

Ask HN: What is the single top-priority software engineering problem?

news.ycombinator.com

331–340 of 364 posts

Re: Ask HN: What is the single top-priority software engineering problem?

#331
post #297

I think making software human-understandable (and by extension modifiable) is one of the biggest problems for software engineering. As it stands, both beginners and experts have difficulties understanding exactly what their own programs are doing as well as what programs written by other people are doing. We encode complex algorithms in static, abstract text descriptions that are hard for humans to understand and rea…

You might want to have a look at Bret Victor's work: http://worrydream.com/

I worked with Bret in his research group :)

Re: Ask HN: What is the single top-priority software engineering problem?

#332

Next level web scraping that takes any web app and fully groks its structure, devolving it to a JSON-like document that encapsulates all form elements, design elements and extrapolates some basic validation rules and the underlying data structure. Load that into a universal editor, work on the metacode. Since we are dreaming, compile that metacode back to any number of frontend/backend combo templates. The result wou…

You might be interested in this project:

https://twitter.com/geoffreylitt/status/1224094967922073600?...

There’s a paper about it coming soon that gets more into some of the things you mentioned.

Re: Ask HN: What is the single top-priority software engineering problem?

#333
post #219

A constantly cycling proliferation of different languages, frameworks, libraries, etc. that all do the same things in a different way and are most often mutually incompatible with each other and have entirely different ecosystems with their own comparative advantages but also major pitfalls. This causes tech workers’ investment in skills to get more out of shallow knowledge and trivia than on deeper concepts, creates…

Totally agree, this is a problem I also see plaguing our industry, and solving it is indeed a priority. We developers or engineers like wasting our time in abstractions, i.e. virtual worlds of isolated castles and babel towers of different languages and expertise. In such virtual worlds we can create and fantasize on all the abstractions we want, be the expert, play god, decide on which constraints matter, and build a world based on that. Such is the power of the non material software world indeed. Who does not want to be god? To caricature I'd say a significant part of the IT industry is about writing virtual entertainment: video games to be sold to the wider public, and toys developers and engineers can play with: languages, IDEs, ecosystems, frameworks, etc.

Earlier in this thread I wrote about data being the top priority [1], the raw material, that we rarely give data the primary focus it deserves and instead focus too much on the processing side. More concretely: dashboards showing instrumented processing clusters give a biased view that does not focus on what matters at the end of the day. What we also need are dashboards showing data flowing between sinks and sources, data quantity, data quality, etc. Sure resource utilization and efficiency matters, but only after we can validate we still have the right output, and that input is of proper quality. If output contains garbage, is it bad processing or is it garbage from the input? And if something is wrong with processing, do we know the impact downstream? In other words instrumentation should include data sensors, not just processing sensors: data counters, validation points, invariants, etc. Because at the end of the day, when the power goes off, do you know what's left to recover? Do you prefer your customers telling you about an unfulfilled order or do you rather want it to be detected earlier? If you get audited for GDPR, do you have a map of your sensitive data? In terms of security, is it about protecting clusters and containers, or is it about protecting the data? Once you get the data side right many things become simpler, but if you get it wrong, as we often do, we create a world of problems. Giving data its proper place in our engineering practices will certainly change our industry for the better and bring it closer to "reality" with less danger of veering into the virtual for the sake of it.

In a world where software is increasingly involved in human activities this would have a great impact. However I don't think we should stop there, as I believe this is part of a larger trend I'm concerned about: the idea that, not just in software development but in most human endeavors, we're increasingly favoring spending time in virtual/man-made spaces and activities, at the expense of the real world, the place and time we're at, nature and the environment. As if we want to escape the physical conditions we're in: whether it's our body, our environment, society, the work we do, etc. When one can't see a way to influence the real world a tendency would be to start operating in a virtual one where we get the illusion to have an effect, make some money, be an expert, etc. Oh and let's not forget this desire to put as much tech between us and the real world, as if we don't want to experience it directly, it's too icky, and instead need devices to offer an indirect perception: wearable tech, navigation by GPS, remote controlling tractors in vast industrialized agricultural fields, etc.

A friend working in a supermarket chain told me this story: he often advised a younger manager to consider better maintenance procedures of their A/C system, but to no effect. Now that my friend is retiring soon this younger manager is proposing to make an excel chart to track energy consumption in order to optimize setpoints, and asks my friend for his approval. Really? Approve perception to be limited to an excel chart? Isn't that the same as leaving the windows open and wanting to change the setpoint?

[1] https://news.ycombinator.com/item?id=22277875

Re: Ask HN: What is the single top-priority software engineering problem?

#334
Single top-priority for software engineering - testing to improve quality. If a lot of organisations are still not writing 100% test coverage to reduce ops and increase reliability with quality then something is broken. It's mostly got to do with engineering culture itself. Google famously did Testing on the toilet experiment which paid off.

https://testing.googleblog.com/2007/01/introducing-testing-o...

Re: Ask HN: What is the single top-priority software engineering problem?

#335
writing tests requires sometimes thousands of lines of boilerplate like setting up mocks, crafting assertions, isolating the test environment and data, etc. testing is important but engineers hate doing all the leg work to set them up. if someone could write a testing engine to sort of ‘lock in’ the implementation of a function or class and then automatically alert the developer when the implementation deviates from the locked version’s spec (determined by automatically profiling the functions input and output on a continuous basis) that could improve testing and vastly reduce the amount engineer hours spent on writing tests

Re: Ask HN: What is the single top-priority software engineering problem?

#336

State observability for the entire stack.

+1 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.

Thanks I’ll take a look

Re: Ask HN: What is the single top-priority software engineering problem?

#337

Documentation! I am willing to go out on a limb and say that as much as 25% of software engineering time worldwide is wasted due to poor documentation. It's an asymmetric problem too. If someone benevolently funds a team of engineers for a couple of months to write great docs (with detailed examples) for top 500 libraries, frameworks, APIs. They could increase global productivity of software engineers by %25 percent.

[deleted]

Re: Ask HN: What is the single top-priority software engineering problem?

#338

Documentation! I am willing to go out on a limb and say that as much as 25% of software engineering time worldwide is wasted due to poor documentation. It's an asymmetric problem too. If someone benevolently funds a team of engineers for a couple of months to write great docs (with detailed examples) for top 500 libraries, frameworks, APIs. They could increase global productivity of software engineers by %25 percent.

A very conservative estimation! And it's not only documentation of software but also the requirements and other parts of the whole lifecycle. It's incredible how many companies hold meetings after meetings to keep up the oral tradition only to run in circles. Instead of POs who churn out dozens of irrelevant tickets, we need people who can tell and write stories - real stories not "user stories". They offer insight, motivation, engagement and the right understanding to break down the work into reasonable and deliverable bits.
Post reply on HN