Well, ideally, we’d want to just say what the other system is, and have that be executable! And I think this may be feasible.
-
-
Replying to @Meaningness @ctbeiser
Many of the most important bugs result from slippage between what the programmer thinks data structures are representing and outside world.
1 reply 0 retweets 1 like -
Replying to @Meaningness @ctbeiser
In this vein, this paper is worth a read. "Subject-oriented programming" - https://pdfs.semanticscholar.org/bdb2/ed51f2d471c730aea28b3692f63d5c478e0b.pdf …
1 reply 1 retweet 3 likes -
The entire requirements engineering and architecture sub-disciplines of software engineering deal almost exclusively with these issues.
1 reply 1 retweet 0 likes -
Replying to @etscrivner @ctbeiser
Yes! But, at least when I was in school (late Victorian era) requirements analysis was not taught. Has this changed?
3 replies 0 retweets 0 likes -
Replying to @Meaningness @etscrivner
I had a class on "Software Development" that was actually about requirements engineering—but not explicitly. The process was as follows:
2 replies 0 retweets 0 likes -
is there recommended reading on requirements engineering?
2 replies 0 retweets 0 likes -
1 reply 0 retweets 1 like
-
Replying to @ctbeiser @The_Lagrangian and
I jest slightly but: that, "Thoughtful Interaction Design" (specifically on Fully Dynamic Dialectical Processes) and https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/ …
1 reply 0 retweets 0 likes -
Replying to @ctbeiser @The_Lagrangian and
Oh, and probably an excerpt from Suchman's "Plans and Situated Action"
1 reply 0 retweets 2 likes
This book changed my life
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.