Live data from Hacker News

The collapse of complex software

nolanlawson.com

301–304 of 304 posts

Re: The collapse of complex software

#301

One great tool for fighting complexity is to Always Consider Option Zero: whenever comparing possible solutions to a problem, consider the option (Option Zero) where you simply don’t solve the problem. It’s amazing how much it changes the conversation when you stack up the pros and cons of the status quo, against the pros and cons of each solution. Quite often you realize the best path is much simpler than you though…

It always feels like a huge win to successfully make the case _not_ to build something we don't need. Unfortunately it's hard to make the case for such work in performance reviews.

Re: The collapse of complex software

#302

Earlier quoted context omitted.

I want to believe you, but there are just so many complicated problems IN REALITY that we have to model in software that I don't really see complexity going down. Just an example: around here, most people have a first (given) and a last (family) name. If I don't model that as separate, I have trouble interfacing with other software. If I do, I have trouble with people from other cultures that don't follow that conven…

The rabbit hole on names goes deep [1]. Lots of other fun rabbit holes. [2] For how to model physical objects like those cables, go see how Grainger does it as a working practical model. To really handle names properly, you need more context than the name in the presentation layer that many schemas take their modeling from can obtain. Government health care or similar widely-adopted encoding is sometimes Good Enough.…

No post body was provided.

Re: The collapse of complex software

#303
post #72

Earlier quoted context omitted.

I want to believe you, but there are just so many complicated problems IN REALITY that we have to model in software that I don't really see complexity going down. Just an example: around here, most people have a first (given) and a last (family) name. If I don't model that as separate, I have trouble interfacing with other software. If I do, I have trouble with people from other cultures that don't follow that conven…

> Names Don't try to force schemas onto schema-less data. Store the "name" as a JSON string/blob representing the various possible attributes (given, middle, family, title, etc) and provide a variety of functions for representing that data. IF you really need to do this at all (for an internal app, you probably don't). > Physical links Include an Hardware Asset FK in your Link M2M table. Model each binary link explic…

I could be wrong but using JSON as format for name is not a solution, its abstraction over possible solution. Suppose we store all names as JSON structure. Question - how people will create such structure from their names? Using form with dozens of fields and checkboxes? Second question: how we will display this structure? We have to find a way to convert this JSON into string to show name. And as result we will surely need function to convert this shown strings into JSON for sure. And how we can solve issue when some names could be presented as a bit different JSON structures? And how we can validate that these slightly different JSON structures are equal?

Re: The collapse of complex software

#304

Earlier quoted context omitted.

Get in touch! I work within KX as a Solutions Architect and would love to see how we could help you out. [redacted]

Will do at some point. Thanks for the invite!

Anytime! FYI we've released a new product KX Insights which is a cloud native version of kdb+ that supports ANSI-SQL (PostgreSQL) and has a bunch of ease-of-use and interoperability improvements to open the technology to a much wider user base :)
Post reply on HN