Ask HN: What problems your industry has that desperately need a solution? | Hacker News Reader

Ask HN: What problems your industry has that desperately need a solution?

15 pointsever_curious24 comments

I work in tech, and we really need to find a way to get tech companies to move from the bay area to different metro areas in the country.

Voting for taxes on tech companies should do the trick?

This is starting to happen I think. The economics are starting to make sense, for some companies, due to insane rent and cost of employees.

There are no young new workers in the construction trades.

Average age of some trades is now 60 and these are not trades typically performed by older generations.

Wages are rising but I believe there exist opportunities to use AR to transfer tacit knowledge - the type of knowledge thought to be difficult or impossible to formally educate.

I believe solving for x on this problem has higher order side affects that we don't presently anticipate because this topic is a neighbour to long standing mysteries in AI.

I would love to ask you a couple of questions.

Do you have an email or social media profile where I could reach you?

See my HN profile.

PS: Your email is not view-able from your HN profile. Test in a private browser tab

Not sure why that's set to private and don't see an option to make it public.

Here's the address: delete-username-dashes-only-i-n-t-e-r-n-a-u-t@internet-mail.org

I think that you have to write it in the about field in your profile page

Of course! Seem to be a bit dim today. I'll blame it on the weather. It is raining and the sky doesn't have a colour.

Oh and sorry, but remove the dashes - from the email address username.

Did you mean an EPC company ?

No.

I blame this on the attitude that everyone needs a 'College Degree'. It has caused people to not value real work the way they should.

That is true, and partially as a result it will shortly be that blue collar labour will earn higher wages than white collar labour. That and many important tasks will remain unaccomplished like people having houses to live in or clean environments.

This happened before in the early 20th century when middle class abruptly had to learn to cook and clean because their cooks and maids went to work in the factories - used to be true that human labour was very cheap.

In my day job, I work as an advisor to UHNW families and individuals. They have their investments spread across multiple institutions, each providing their own monthly statement, holdings, etc. Our clients pay 4-figures fees monthly to have a consolidated statement (how much money I earned on August, what has been my return YTD, etc.) and portfolio holdings (How much fixed income do I have? How much I am exposed to the Turkish lira? to Argentinian stocks?). Most of the information is in the individual statements (in pdf) and the rest from providers such as Bloomberg and Morningstar. The solutions out there are custom-made and have a lot of manual input. I think a bit of AI and good visualizations can go great lengths to solve this problem.

I found it incredibly difficult to find part-time (20-30 hours per week) work. It was even more difficult to find it remotely.

Older thread (9 years): https://news.ycombinator.com/item?id=893529

I work in Fintech, I think training people on how to write good requirements and specifications is lacking

It's not just in Fintech, it's a problem in most industries, I deal with it in automation most days. It's a skill that is not easily leaned (well).

I am finding the same issue in many areas.

But I am asking myself if it is just lack of knowledge and knowhow or is it also lack of time, processes and tools for writing and maintaining requirements.

My observations are that along with not knowing how to gather and write requirements people at the project level also threat them as second hand objects for the success of project.

Eg: some people in agile talk about requirements being user stories with clarifications and decisions around them. Other people say that in agile requirements are conversation starters.

In a way these might be good points but also it creates the impression that we should not invest quality in requirements. As it will anyhow change.

What I find is that many people do not consider different edge cases or understand what the data really represents. They have some vague notion of what they want, and you only get that very high level limited case.

They almost need some training on how to think like a program in some sense to understand just how much detail is needed to provide a good spec.

It is a common problem. Although it can be improved it can NEVER be fixed. Why? Because until they see it and use it they will not be inspired to say 'Well why did you not ...' Until they have the product they did not know they had a requirement xyzzy.

I remember a computer history class, where the teach mentioned time sharing was invented in the mid 60's and one guy was insistent it should have been invented earlier. He felt the requirement was always there, and should have been done in the 40's...

Requirements are rarely independent of each other, and sometimes they're sourced from different people and organizations.

A key problem with many requirements documents is that they're documents (often in Word if "formal", or communicated via email or similar otherwise). You have to be able to separate out the individual requirements and understand the difference between requirements and specifications.

A requirement is what it most do, a specification is how. So if a customer has levied a "requirement" of "Using Java, create classes to handle the following...". That's a spec (even a design doc, really), not a requirement. So get them to answer the why of it. Maybe you're writing something to run on their existing app server, so Java as a requirement makes sense. But maybe that's just what they're familiar with, and so should be dropped or altered.

Next you need to start collecting all the requirements. Maybe some come direct from the customer (The system MUST display account balance). But maybe it comes from a legal authority (The system MUST flag all transfers over $10,000). Find those and list them out. Some of these requirements will be linked to each other, figure out which. And when you get to developing specifications, it's the same.

"SPEC-10345: In order to meet regulatory requirements a log will be maintained of all transactions over $10,000 <REQ-10011>. SPEC-10346: This log will be retained for a minimum of 3 years <REQ-10012>.". That link allows you to know the element of the specification isn't arbitrary, it has a reason. And by linking you can update the related spec when the requirement changes. The law changes next year and the threshold increases to $20,000. Update your requirement and all linked requirements and specs will be flagged for review. Now you know to update this specification element, and the code which implemented it.

But the hard thing is, this has to be automated and disciplined. Either with custom tools (all this written in plaintext and hand written perl or whatever to generate reports and analyses) or an actual requirements database software solution. Every project I've been on where they insisted on using Word (or Excel, only slightly better) for this has been a cluster fuck when it comes to maintenance and tracking later on. You can afford to be slack on this in many industries, but where there are significant legal and regulatory elements or safety factors to consider this is critical.

Writing out these more formal specs and requirements you'll also find those edge cases you mention in another post (though not all). It'll be obvious when a requirement isn't satisfied by any specification elements. And on review, when a specification element doesn't actually satisfy the related requirement.

Reply on news.ycombinator.com