I'm curious from anyone who has read through these... How solid scientific footing are these on? Is it closer to mathematics, or closer to psychology? (Proofs tend to stick more in the former than the latter)
If you want an overview of the ideas behind this sort of research and a quick summary of some results, Greg Wilson gave a great talk on it[0].
I haven't read through the site to see what is there, but software engineering methodology and technique research* uses techniques from research of management techniques in business, making it closer to psychology or sociology. For more information, the blog "It Will Never Work in Theory"[1] does a good job of highlighting these sorts of results that are directly useful and has some explanation of the tools they are using to study software engineering practices. The book Making Software[2] goes into much more detail on software engineering research methodologies if you are interested.
*As opposed to CS theory research that could be used in software engineering, which is usually math.
Thanks! I had Making Software on my bookshelf, and someone "borrowed" it. I'll need to "borrow" it back. :-) The challenge from it's intro was that anyone in the field will overstate the truth in the research. I used to be a business book junkie until I realized what weak foundation most of it was built on. I've gradually come back to the genre but more for context and story than predictive power.
The Halo Effect [0] amped up my skepticism. Of course it was a business book [1] that introduced me to the Halo Effect... :-)
quick review. my opinion can change. THUMBS DOWN. 1 out of 5 stars.
why? remember I am not as smart other disclaimers.
THIS IS THE METHOD I AM USING after 38 or so years and yes I have
dropped the box with Fortran punch cards. OOPS.
1.)it a human process - worthless.
2.)only human process worth while in REAL time is this site and reddit dot
com / haskell, etc.
3.)where is the ontology?
4.)i also provide real perspective by
a.)rosetta code - go ahead and laugh but code translation is helpful
especially between OOP python, C and FP Haskell
b.)encylopedia of int sequences. Help me find more mistakes in the
int sequences for I so far CANNOT FIND ANY.
8.)What a shame. the evidence of the Heartbleed Bug that broke the internet is on git. One way to find the BLAME is git blame.
What are the other THREE WAYS???
9.)IMHO, it is NOT an EVIDENCE database. Provide evidence and a
few toolsets.
10.)Even simple metrics like WHAT IS THE TREND LINE MOVING CHART
like yahoo finance stocks for 'changes', BUGS, vulnerabilities and
HEAT MAP - changes.
11.)Heat map changes?
a.) Coder stated design
b.)goals and constraints
c.)code diff
d.)code metrics - EVIDENCE
e.)code analytics - EVIDENCE
f.)redditc snarky comments - sometimes evidence
g.)....
No, the evidence does NOT have to be extreme detail, however the
test framework: S M A R T
S for specific - related to ontology or BoK or ??? or ?? scrum?
is needed. Haskell wording is VAGUE, context specific, scoping?,
strange logic - Template Haskell and Liquid, etc., etc.
haskell is an example.
Engineering is the middle layer between the hacker - anything goes
technically to the Science and then to the Math.