4 ms·
Weekend reading material found, thanks! While not as well-thought out and presented, I've been working on a similar project for the past 6-8 years. I called it
by vinodkd 9y ago
Weekend reading material found, thanks!
While not as well-thought out and presented, I've been working on a similar project for the past 6-8 years. I called it the "Grand unified theory of software" (after its physical equivalent) [1] and the attempt was to define, describe and quantify code, how its created, and changed.
The best exposition of my thoughts is probably this mindmap:[2], but the TLDR version is:
* Software has size. Sequences of code adds height, modules add width; together giving area
* Software has weight, like page weight or memory weight.
* Forces act on software to change it, and they could be design constraints, organizational will, etc
* Code is data REALIZED, data is code ABSTRACTED
* and so forth
There is also a book (not mine) called the "Grand Unified Theory of Software Engineering"[3] which takes into consideration not just what software is, but the processes and organizations that cause it to be created and explores justifications for statements like "you ship your organization", for example.
We need more such exploration and discussion, IMO. Since software is largely an abstract thing, having models to help thinking about it in ways analogous to concrete things is useful, if not precise.
1: https://github.com/vinodkd/guts https://github.com/vinodkd/guts
2: Mindmap flash version: http://vinodkd.github.com/guts/mmap/full/guts.html http://vinodkd.github.com/guts/mmap/full/guts.html
Mindmap non-flash version (look below diagram for complete text): http://www.vinodkd.org/guts/mmap/basic/guts.html http://www.vinodkd.org/guts/mmap/basic/guts.html
3: GUTSE: https://books.google.com/books/about/The_grand_unified_theory_of_software_eng.html?id=TLcceL3NEiMC https://books.google.com/books/about/The_grand_unified_theor...
- jerf 9y agoHaving scanned over some of what you link, I would suggest learning a bit about fractal geometry and the possibilities of non-integer dimensions. I suggest this because code and modules probably don't multiply exactly as an area. This will be especially true if you try to go beyond 2D, because the discrepancies between the full R^n space and what software actually does (streak through it in something like a powerlaw distribution) will become worse and worse. (See something like https://physics.stackexchange.com/questions/55269/why-do-fractal-systems-show-power-law-behavior https://physics.stackexchange.com/questions/55269/why-do-fra... .) See also some ideas in https://codeburst.io/software-estimation-in-the-fractal-dimension-914569e2ccb9 https://codeburst.io/software-estimation-in-the-fractal-dime... or https://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=24b https://www.quora.com/Engineering-Management/Why-are-softwar... for more thoughts that head in that direction.
- vinodkd 9y agoYes, I was heading in that direction, while having misgivings about using terms like area. The advantage is that its a familiar term, the disadvantage is that its really not the same physics (if there is one to be found). Thanks for the links