3 ms·

I think you're basically correct and certainly nothing you say is wrong. I construe pleasantness a little more broadly. The pleasure target for b2b software is

by User23 3y ago

I think you're basically correct and certainly nothing you say is wrong. I construe pleasantness a little more broadly. The pleasure target for b2b software isn't the people using it, it's the people signing the purchase orders. And for some reason those people find execrable garbage like a certain extraordinarily slow and wildly overcomplicated project management package that's extremely popular in "the enterprise" pleasant enough to sign giant checks for, to give just one example. I think with that semantic modification we appear to be pretty much on the same page? Additionally, I've shared some of those insights you mention. I would go a little bit farther and say that actually formally stating those from-the-heavens requirements would improve software quality and possibly even increase pleasantness for the principals in question, that is at least supposing they actually know what it is that they want. A hard "ask" I know.

Kamq 3y ago
> I would go a little bit farther and say that actually formally stating those from-the-heavens requirements would improve software quality and possibly even increase pleasantness for the principals in question Do you think so? It seems to me that they change with little to no warning, and so long as the business is willing to pay for the change, I can't see anything about them being objectively wrong. Is the value just calling out the things that are most likely to change in a single place?
- User23 3y ago
  There’s certainly value there, but to give Mr. Hickey his due informal reasoning has been, in my experience, mostly adequate for properly separating those kinds of concerns. I would like to think we can do even better though, and so far as I can tell those sorts of informal methods have been refined to essentially peak performance. I expect there is opportunity for business friendly consequences like proving that no edge case exists that can drain your wallet.
- naasking 3y ago
  Formally specifying requirements earlier often reveals inconsistencies and limitations that otherwise only users will reveal in acceptance testing or after deployment.

by User23 3y ago

Kamq 3y ago

> I would go a little bit farther and say that actually formally stating those from-the-heavens requirements would improve software quality and possibly even increase pleasantness for the principals in question Do you think so? It seems to me that they change with little to no warning, and so long as the business is willing to pay for the change, I can't see anything about them being objectively wrong. Is the value just calling out the things that are most likely to change in a single place?

User23 3y ago
There’s certainly value there, but to give Mr. Hickey his due informal reasoning has been, in my experience, mostly adequate for properly separating those kinds of concerns. I would like to think we can do even better though, and so far as I can tell those sorts of informal methods have been refined to essentially peak performance. I expect there is opportunity for business friendly consequences like proving that no edge case exists that can drain your wallet.
naasking 3y ago
Formally specifying requirements earlier often reveals inconsistencies and limitations that otherwise only users will reveal in acceptance testing or after deployment.