SEED: Software Engineering Evidence Database (opens in new tab)

(evidencebasedse.com)

29 pointscipher011y ago6 comments

6 comments

6 comments · 3 top-level

mathattack11y ago· 2 in thread

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)

chas11y ago

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.

[0] http://vimeo.com/9270320 [1] http://neverworkintheory.org/index.html [2] http://shop.oreilly.com/product/9780596808303.do

mathattack11y ago

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... :-)

[0] http://en.wikipedia.org/wiki/Halo_effect [1] http://www.amazon.com/The-Halo-Effect-Business-Delusions/dp/...

commentei2911y ago· 1 in thread

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.

CaveTech11y ago

I honestly have no idea what you're going on about.

klibertp11y ago

Nothing about readability... I guess there really are no studies on what readability is and how to measure it and how to write readable code :)

j / k navigate · click thread line to collapse