TDD Classification

[Marcus Milanez]

Hello everyone,

I'm conducing my masters research on TDD (more specifically, on the economical, psychological and technical aspects of TDD) and came across some questions that are making me feel confuse.

The first one is: How exactly can we classify TDD?

On Kent Beck books we can find that TDD is a development technique/style (TDD By Example). Robert Martin says that it is a discipline (Clean Code). Martin Fowler says that it is a design technique (http://martinfowler.com/bliki/TestDrivenDevelopment.html).

My question is: Assuming that TDD is a technique/style, what are the other existent techniques/styles available for proper comparison ? How about disciplines. is there a list of available development disciplines that I can query ? What are the other known and documented design techniques?

On WikiPedia (http://en.wikipedia.org/wiki/Test-driven_development), TDD is classified as a "Software Development Methodology" but in my humble opinion this is not accurate. The definition of software development methodology as described by Ian Sommervile in "Software Engineering" is: "... a set of structured approaches to software development which include system models, notations, rules, design advice and process guidance.". This definition seems to be appropriate for Software Development Life Cycle models such as Waterfall, Spiral and Scrum, but not TDD. Does that make sense?

While thinking through this, I started thinking of TDD as a problem solving strategy but this is not clear enough for me.

As always, thanks in advance!

--

Marcus Milanez

[Marcus Milanez]

Just rephrasing myself:

While thinking through this, I started thinking of TDD as a problem-solving strategy, as described by cognitive psychologies, but this is not clear enough for me yet.

Thanks!

Marcus

2013/4/16 Marcus Milanez <mmil...@gmail.com>

--

Marcus Milanez

[Olivier Azeau]

Hello,

Off the top of my head I can list OMT (Object Modeling Technique) and
SADT (Structured Analysis and Design Technique)

Regards,
Olivier

[Ted M. Young [@jitterted]]

Hi Marcus,

I'm curious, how will you use this classification? To compare against other similarly classified techniques?

I personally look at TDD as a design process. To call it a problem-solving strategy seems to be too broad as many software development activities are about problem-solving and there are lots of strategies.

;ted

--

http://about.me/tedmyoung

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsub...@googlegroups.com.
To post to this group, send email to software_craftsmanship@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Marcus Milanez]

Hmmm interesting point Olivier, thanks!

In this case, a proper classification for TDD would be 'Design/Modeling technique', correct?

Marcus

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.

To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.

Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--

Marcus Milanez

[Sleepyfox]

TDD is all of the above. To understand, practice it for a while and then come back to us with your thoughts.

Fox.

[Marcus Milanez]

Hi Ted,

Yes this is the idea. I would like to compare TDD to other similar techniques that helps developers reaching their goals. I would like to describe the strategies followed by each of them, to elucidate TDD in a proper context. 

Thanks!

Marcus

To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.

Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Marcus Milanez

[Marcus Milanez]

Thanks for the advice Fox. Sorry if I'm still trying to learn what many of you already know ;)

Marcus

--

Marcus Milanez

[J. B. Rainsberger]

On Tue, Apr 16, 2013 at 12:59 PM, Marcus Milanez <mmil...@gmail.com> wrote:

 

I'm conducing my masters research on TDD (more specifically, on the economical, psychological and technical aspects of TDD) and came across some questions that are making me feel confuse.

The first one is: How exactly can we classify TDD?

1. A set of rules: no production code without a failing test; improve the design any time the tests all pass; commit the code to version control any time the tests all pass.

2. A design technique in which the programmer defers design decisions until e[1] has to make them and remains willing to change those decisions when e learns something new.

3. A learning-to-design technique in which the programmer learns to classify "good" and "bad" design by pattern recognition, similar to the way humans learn to speak languages.[2]

4. A generalised problem-solving approach in which a person articulates clear, testable intermediate goals before attempting to reach them, integrating feedback from reaching earlier goals into setting later goals.

[1] https://en.wikipedia.org/wiki/Spivak_pronoun

[2] http://bit.ly/gmeMhh

--
J. B. (Joe) Rainsberger :: http://www.myagiletutor.com :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com

[J. B. Rainsberger]

On Tue, Apr 16, 2013 at 12:59 PM, Marcus Milanez <mmil...@gmail.com> wrote:

 

My question is: Assuming that TDD is a technique/style, what are the other existent techniques/styles available for proper comparison ? How about disciplines. is there a list of available development disciplines that I can query ? What are the other known and documented design techniques?

Alternatives to TDD:

* test-first programming (my personal definition), in which the programmer attempts to design the system up front in detail, then uses tests to "type it in correctly", used mostly as a defect-avoidance technique, but not allowing for the design to evolve, as TDD does

* unit testing or test-after programming, in which the programmer writes and runs automated tests in cycles of varying size, but without insisting on writing the tests before writing the code that passes those tests

* code and fix, in which the programmer writes larger amounts of code, then tests it (perhaps with automated tests, perhaps with manual tests, perhaps by letting other people try to use it), then attempts to fix as many discovered defects as possible before time or budget or patience runs out

The essence of TDD is:

* no code without tests

* just enough code to pass the tests

* ongoing design improvement

* very few design decisions up front

* tight feedback loops (measured in seconds/minutes)

* clearly articulating intermediate goals as precise automated, repeatable tests

To create an alternative, take each of these things away one by one, then two by two, then three by three…

-- 

[George Dinwiddie]

Marcus, J.B.,

Yes, and
* evolving the design by asking "what do I next want to ask this code
to do?" rather than "what do I next want to implement?"

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Remon Sinnema]

Hi Marcus,

As others have pointed out, TDD is different things to different people. I haven't tried to classify TDD along all those dimensions, except for TDD as a testing technique:
http://securesoftwaredev.com/2012/09/03/a-classification-of-tests/

BTW, I did this mostly because I wanted to show that TDD is *not* primarily a testing technique. Some people have a hard time looking past the word "test", so the name is a bit unfortunate.

Thanks,
Ray

[Grzesiek Gałęzowski]

As one of the alternatives, you might look at Programming By Intention:
http://www.netobjectives.com/resources/programming-intention.

Actually if you try, you can combine it with TDD, but as I see it, outside-in, mock-based TDD can be viewed as "Programming By Intention++".

You can also read my blog post where I make an attempt to compare the two:
http://feelings-erased.blogspot.com/2013/01/single-method-perspective-vs-single.html

Best regards,
grzesiek gałęzowski

[Michel Löhr]

BDD could be called a progression of TDD, both can even be combined.

To understand TDD or BDD you fall short if you only understand the practices.

You need to understand the principles and mindset, usually this is only gained by going through the learning-curve yourself.

Good source of references on BDD can be found in the link below. Somewhere in it there exists "discussions" on why and how BDD came into existence although TDD was already available...

http://goodrequirements.com/bdd/#axzz2C8mu2TjY

May the force be with you ;)

[Marcus Milanez]

Michel,

Thanks for your assistance. I also appreciate all the other comments posted!

The most difficult part for me right now, is to add write down all the researches I've been collecting in an appropriate academic format. I need to include references to existing researches that can provide support to what I'm intending to explain. Our profession, in my humble opinion, still advances much faster in the industry than it does in the academic world. It is easy to find someone's opinion, it is easy to empirically agree with what the industry is saying, but it is really hard to find a published research that can prove that this given "opinion" is correct and based on theories that validate them. I'm trying to get my research based on Antony Hoare, Michael Jackson (not the singer :D), Jerry Weinberg, Berry Boehm, Fred Brooks, Ivar Jacobson and Charles Peirce works basically. Of course I couldn't miss Uncle Bob and Michael Feathers awesome books, but the foundation of my research is based on the previous authors books and papers.

By the way, one very interesting article I've read recently is Mary Shaw's paper about Software Engineering. Maybe this is very 'basic material' for you, but I wanted to share it with you all anyway http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/bullet08.pdf . Her observations about the evolution of other Engineering fields is fantastic, IMHO.

Thanks everyone!

Marcus

2013/4/24 Michel Löhr <miche...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Marcus Milanez

[Sleepyfox]

Software is not Engineering. That ship has sailed. Please don't fall into the same trap that so many others since the 1968 Garmisch conference have done. 

Fox

--

[Marcus Milanez]

Software is not Engineering.

Did I ever say that?

2013/4/24 Sleepyfox <slee...@gmail.com>

--

Marcus Milanez

[Michel Löhr]

Marcus, thanks for your interesting reply.

Regarding your research, the question I see is how you want to measure it (what improvements)?

I know of some research regarding productivity done by Casper Jones:

Capers Jones and his productivity experts at Software Productivity Research who 

analyzed and reanalyzed the output of early Scrum teams, as well as many of the software 

products built with Scrum during 1994-2000.

 This is being referred to in the Scrum papers: http://jeffsutherland.com/ScrumPapers.pdf

And here you could find more research data: http://jeffsutherland.com/ScrumMetricsHICSS2013BWSubmissionFinal.pdf

Cheers, Michel

[Raoul Duke]

so... is there no engineering inside the realm of 'software' at all?

[Sleepyfox]

You promoted Mary Shaw's 1990 paper, linked in your previous email, which is entitled 'Prospects for an Engineering Discipline of Software'. You also used the phrase 'the other Engineering fields', so, yes - pretty much :-)

Fox

--

[Sleepyfox]

The whole Software Craftsmanship movement, founded on the basis of Pete McBreen's seminal work 'Software Craftsmanship: the new imperative', starts with the assertion that 'Software is not Engineering'. So if you want to have that particular discussion I wouldn't bet on your chances of finding many sympathisers in this particular group ;-)

Fox

-- 

P.S. For the pedants like myself amongst us: McBreen did say that there is rarely any (rather than a complete absence of) Engineering in software, except in those projects in which both software and hardware is designed together, which is a small minority of the entirety of software development projects.

[Raoul Duke]

i will try to repeat in a different way what i was trying to say. :-)

"A is not X" can be read as "there is absolutely no X at all anywhere
to be found inside the entire gamut of A", or it can be read as "at
the high level view, A and X are not the same".

i personally cannot accept at all that there is no engineering
anywhere in "Software", while i can accept that "Software" is not 101%
pure engineering.

[Marcus Milanez]

OK Fox, thanks for your observations, I appreciate them. I'm not trying to defend a particular position, and I'm really sorry if my words sounded arrogant or stupid.

My main objective here is to learn, so I guess I should just read the messages as they arrive in my inbox.

Thanks!

Marcus

2013/4/24 Sleepyfox <slee...@gmail.com>

--

Marcus Milanez

[Sleepyfox]

Marcus - no need to apologise. I do very much recommend that you read McBreen's book, it is IMHO a 'must-read' for every serious professional developer, whether you agree with the author's position or not.

Fox

--

[Jim Weirich]

On Apr 24, 2013, at 5:03 PM, Sleepyfox <slee...@gmail.com> wrote:

> Marcus - no need to apologise. I do very much recommend that you read McBreen's book, it is IMHO a 'must-read' for every serious professional developer, whether you agree with the author's position or not.

Glenn Vanderburg's talk "Real Software Engineering" is also a good take on the subject. Highly recommended.

http://www.confreaks.com/videos/550-scotlandruby2011-real-software-engineering

--
-- Jim Weirich
-- jim.w...@gmail.com

[Raoul Duke]

bad link that one for me, the video didn't play
so i went to
http://www.youtube.com/watch?v=NP9AIUT9nos
and am enjoying it a lot.

[Raoul Duke]

(Edward Tufte is rolling in his grave, so to speak.)

[Marcus Milanez]

Fox,

I truly respect your and everyonelses observations. I live in a country where democracy is respected, so instead of opressing opinions that differ from my point of view, I respect them and reply with polite observations to have a high level discussion where everyone has the opportunity to learn. Oppression often leads to the opposite way, and besides, I'm far from being the owner of the truth.

I'm glad you shared these links from McBreen, I'll study them carefully. I just hope they don't represent the absolute and incontestable  truth that can't be questioned by anyone. I also hope that the author has its ideas based on science, not on personal postulates. I'm not saying that I don't agree with this approach, but I think that there are important  aspects on scientific approaches in many cases - I wouldn't blindly take an untested medicine, just because someone created it claiming that it can have all my diseases cured.

I respect very much the software craftsmanship initiative, I try hard to study and learn what people like Uncle Bob, Michael Feathers and Corey Haines are constantly and respectfully teaching us, but I don't think Craftsmanship has its back turnes to discussions of this kind, using arguments such as "you won't find sympathisers if you want to discuss some subjacts" . I don't think it discourajes the use of scienctific approaches to have its methods proven and evaluated, too. According to the dictionary for example, engineering (not of any specific discipline) means the following: " the application of scientific and mathematical principles toward practical ends" - isn't what we, software developers/craftsmen/programmers/ try to do everyday? Ins't TDD a pratical implementarion of the mathematical invariants theory, adapted to computer science also as "invariant" by Tony Hoare? Aren't abstract data types another mathematical model adapted to our discipline? Do we really need to say that we should forget about math and science at all in our profession? Can't we discuss these subjects in a high level amongst software craftsmen/women?

Again, I'm not saying that software development is or should or shouldn't  be considered and engineering discipline (although, personally, I find the researches performed by Mary Shaw very interesting - she says that software development is not an engineering, rather we still are at craftsmanship level, but there is potential for an engineering discipline, maybe not as we currently understand engineering though) I'm just saying that whenever we strongly  say that something "is" or "is not" something else, we must be backed-up by rigorous proofs that can confirm what we are saying - otherwise, instead of doing science, we'll be blindly following a religion. 

Following this rationale, I consider Greg Wilson's position very important. I'd greatly appreciate if you could see these presetations and get back with your opinion

http://www.slideshare.net/gvwilson/bits-of-evidence-2338367

http://vimeo.com/m/9270320

I appreciate your patience and respect.

Respectfully,

Marcus

--

Marcus Milanez

[Michel Löhr]

Fox That is off-topic and I don't agree with you. Only real Software Engineering is not easy and 90% (may be even more) of SW developers are not capable of doing real SW engineering. That means having measurable requirements (also the quality attributes), like the way Tom Gilb is propagating. And doing "real" analysis & design and architecture according to Tom Gilb, Gerald Weinberg and others..

2013/4/24 Sleepyfox <slee...@gmail.com>

You received this message because you are subscribed to a topic in the Google Groups "software_craftsmanship" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/software_craftsmanship/NnncqdVyTeo/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to software_craftsma...@googlegroups.com.

To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Kind Regards, Viele Grüße, Vriendelijke Groet,

Michel Löhr

[Michel Löhr]

2013/4/24 Marcus Milanez <mmil...@gmail.com>

--
You received this message because you are subscribed to a topic in the Google Groups "software_craftsmanship" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/software_craftsmanship/NnncqdVyTeo/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to software_craftsma...@googlegroups.com.

To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Michel Löhr]

Fox on second thoughts may be you are right, but it has potential to become one:

http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/bullet08.pdf

[Adam Sroka]

You can turn anything into a number. Providing useful, actionable information from it that serves the customer is not always easy though. Some of us have found that talking to the customer is often a more productive use of our time than measuring stuff.

[Sleepyfox]

I started to write a long reply about the dysfunctions that arise out of applying proxy metrics, and how we confuse correlation with causation... I deleted it because @Adam said it better. 

This:

On 25 April 2013 03:59, Adam Sroka <adam....@gmail.com> wrote:

You can turn anything into a number. Providing useful, actionable information from it that serves the customer is not always easy though. Some of us have found that talking to the customer is often a more productive use of our time than measuring stuff. 

Fox

--

"Not everything that can be counted counts, and not everything that counts can be counted"

  -- A. Einstein

[Marcus]

Fox,

--

"Not everything that can be counted counts, and not everything that counts can be counted"

  -- A. Einstein

Please don't quote William Cameron as Albert Einstein...

It would be nice if all of the data which sociologists require could be enumerated because then we could run them through IBM machines and draw charts as the economists do. However, not everything that can be counted counts, and not everything that counts can be counted.

You can double check this quotation in his book , "Informal Sociology A Casual Introduction to Sociological Thinking"

http://books.google.com.br/books?id=I6JIAAAAMAAJ&q=%22counted+counts%22&redir_esc=y#search_anchor

Thanks!

[Marcus]

Michel,

Thank you very much for your assistance! I can definitely use that material as a reference!

Marcus

2013/4/24 Marcus Milanez <mmil...@gmail.com>

2013/4/24 Michel Löhr <miche...@gmail.com>

To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsub...@googlegroups.com.

To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Marcus Milanez

--
You received this message because you are subscribed to a topic in the Google Groups "software_craftsmanship" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/software_craftsmanship/NnncqdVyTeo/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to software_craftsmanship+unsub...@googlegroups.com.

To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Marcus]

Another important historical fact that is often confused and that in my opinion needs clarification. It is often said that the term 'Software Engineering' was coined at the 1968 Garmisch conference as Fox pointed out. However, in this 1992 research conduced by Bertrand Meyer, he indicates that this is not correct. Maybe this is pointless in a professional standpoint, but it definitely matters in an academic one.

Again, I'm really sorry if this is not the right group to discuss some aspects of our profession. I'm not trying to defend a given position, I'm not saying that A is right and B is wrong, I just think that trough facts and high level discussions we can certainly learn and improve ourselves.

Below is the link and the text that contains the research conduced by Meyer.

http://www.unl.csi.cuny.edu/faqs/software-enginering/archive/SEorigin

All textbooks on software engineering that I know, and many articles in the
field, claim (that is to say, repeat someone else's claim) that the term
``software engineering'' itself was coined on the occasion of the Fall 1968
Garmisch-Partenkirchen conference on S.E., organized by the NATO Science
Affairs committee.  (See [1] for the proceedings, published several years
later.)

The very term, it is said, was a challenge to the software community to get
its act together and start rationalizing the software production process.

This common wisdom may need to be revised. The August, 1966 issue of
``Communications of the ACM'' (Volume 9, number 8) contains an interesting
``letter to the ACM membership'' by Anthony A. Oettinger, then ACM President.
I must confess I don't know much about the author; he is identified (in the
announcement of his election in the June 1966 issue) as Professor of Applied
Mathematics and Linguistics, Harvard University, and from his picture looks
like a nice fellow.  The sentence of interest appears on page 546 at the end
of a long paragraph, which I have reproduced below in its entirety because by
looking at the full context it appears clearly that Professor Oettinger did
not just use two words together by accident, as it were, but knew exactly what
he was talking about. Here is the paragraph; words appearing in italics in the
original are shown here in upper case.

  ``A concern with the SCIENCE of computing and information processing, while
    undeniably of the utmost importance and an historic root of our
    organization [i.e. the ACM - BM] is, alone, too exclusive. While much of
    what we do is or has its root in not only computer and information
    science, but also many older and better defined sciences, even more is not
    at all scientific but of a professional and engineering nature. We must
    recognize ourselves - not necessarily all of us and not necessarily any
    one of us all the time - as members of an ENGINEERING profession, be it
    hardware engineering or software engineering, a profession without
    articficial and irrelevant boundaries like that between "scientific" and
    "business" applications.''


(The last point would still be worth making today. The end of the second
sentence would seem to indicate that the writer viewed engineering as being
remote from science, but this would not be accurate; in the paragraph
following the one reproduced above, Prof. Oettinger discussed in more detail
his view of the close relation between science and engineering.)

The above quotation is clear evidence that the term ``software engineering''
was used significantly earlier than commonly thought - more than two years
before the Garmisch conference.

What I don't know is whether Prof. Oettinger created the term, or whether it
had been in use before. In the latter case, does anyone know of an older
reference? Is Prof. Oettinger still around to enlighten us?  (For all I know
he could be reading this!)

Switching now our theme from the past to the future: does anyone have an idea
of when some actual semantics might become attached to the expression
``software engineering''? Is 2025 too optimistic?

Reference
---------

[1] J. M. Buxton, P. Naur, B. Randell: ``Software Engineering Concepts
and Techniques'' (Proceeedings of 1968 NATO Conference on Software
Engineering), Van Nostrand Reinhold, 1976.

[Sleepyfox]

Marcus,

This is an interesting find, but one that doesn't (yet) change much,
as one can still say that the 1968 NATO conference marked the
beginning of the popularisation of Software Engineering as a industry
metaphor.

Thank you for the correct attribution to Cameron, your link didn't
work for me, but a complete analysis here helped:
http://quoteinvestigator.com/2010/05/26/everything-counts-einstein/

Time to update my quotes database.

Fox
--
@sleepyfox

>>>>> an email to software_craftsma...@googlegroups.com.

>>>>>
>>>>> To post to this group, send email to software_cr...@googlegroups.com.
>>>>> Visit this group at
>>>>> http://groups.google.com/group/software_craftsmanship?hl=en.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Marcus Milanez
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "software_craftsmanship" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/software_craftsmanship/NnncqdVyTeo/unsubscribe?hl=en.
>>>> To unsubscribe from this group and all its topics, send an email to

>>>> software_craftsma...@googlegroups.com.

>>>> To post to this group, send email to software_cr...@googlegroups.com.
>>>> Visit this group at
>>>> http://groups.google.com/group/software_craftsmanship?hl=en.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Kind Regards, Viele Grüße, Vriendelijke Groet,
>>>
>>> Michel Löhr
>

> --
> You received this message because you are subscribed to the Google Groups
> "software_craftsmanship" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to software_craftsma...@googlegroups.com.

[George Dinwiddie]

Raoul,

On 4/24/13 6:32 PM, Raoul Duke wrote:
> (Edward Tufte is rolling in his grave, so to speak.)

I don't think so. He's still alive.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Philip Schwarz]

Has everyone here seen Morendil's Software Engineering History Maturity Model? http://plus.google.com/115091715679003832601/posts/VBJTGru3PeW

[Michel Löhr]

Hi Marcus, this is a master thesis you could be interested in:

https://jyx.jyu.fi/dspace/bitstream/handle/123456789/41024/URN%3ANBN%3Afi%3Ajyu-201303071297.pdf?sequence=1

Cheers, Michel

Op donderdag 25 april 2013 20:53:24 UTC+2 schreef Marcus het volgende:

[Sleepyfox]

I managed to get the time over the weekend to watch the presentation
video that Jim Weirich posted on Glenn Vanderburg's talk "Real
Software Engineering" from Ruby Scotland 2011. I can thoroughly
recommend it.

I shall now reconstruct my earlier position as: 'Software is not what
most people think of as Engineering (excepting the real engineers)'

Fox
--

>>>>> an email to software_craftsma...@googlegroups.com.

>>>>>
>>>>> To post to this group, send email to software_cr...@googlegroups.com.
>>>>> Visit this group at
>>>>> http://groups.google.com/group/software_craftsmanship?hl=en.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Marcus Milanez
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "software_craftsmanship" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/software_craftsmanship/NnncqdVyTeo/unsubscribe?hl=en.
>>>> To unsubscribe from this group and all its topics, send an email to

>>>> software_craftsma...@googlegroups.com.

>>>> To post to this group, send email to software_cr...@googlegroups.com.
>>>> Visit this group at
>>>> http://groups.google.com/group/software_craftsmanship?hl=en.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Kind Regards, Viele Grüße, Vriendelijke Groet,
>>>
>>> Michel Löhr
>

> --
> You received this message because you are subscribed to the Google Groups
> "software_craftsmanship" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to software_craftsma...@googlegroups.com.

[Marcus]

Thanks for your link Michel! I appreciate it!

Marcus

[robi y]

I understand you're looking for research data, maybe this book could be of help:

Test-Driven Development

An Empirical Evaluation of Agile Practice

Madeyski, Lech

http://www.springer.com/computer/swe/book/978-3-642-04287-4

On Tuesday, April 16, 2013 6:59:26 PM UTC+3, Marcus wrote:

Hello everyone,

I'm conducing my masters research on TDD (more specifically, on the economical, psychological and technical aspects of TDD) and came across some questions that are making me feel confuse.

The first one is: How exactly can we classify TDD?

On Kent Beck books we can find that TDD is a development technique/style (TDD By Example). Robert Martin says that it is a discipline (Clean Code). Martin Fowler says that it is a design technique (http://martinfowler.com/bliki/TestDrivenDevelopment.html).

My question is: Assuming that TDD is a technique/style, what are the other existent techniques/styles available for proper comparison ? How about disciplines. is there a list of available development disciplines that I can query ? What are the other known and documented design techniques?

On WikiPedia (http://en.wikipedia.org/wiki/Test-driven_development), TDD is classified as a "Software Development Methodology" but in my humble opinion this is not accurate. The definition of software development methodology as described by Ian Sommervile in "Software Engineering" is: "... a set of structured approaches to software development which include system models, notations, rules, design advice and process guidance.". This definition seems to be appropriate for Software Development Life Cycle models such as Waterfall, Spiral and Scrum, but not TDD. Does that make sense?

While thinking through this, I started thinking of TDD as a problem solving strategy but this is not clear enough for me.

As always, thanks in advance!

--

Marcus Milanez

[Marcus]

Robi,

Thanks for this indication! I'm wondering why this book is so expensive (USD99 for the e-book format) though. Have you read it already?

Marcus

[robi y]

Not really...

Here's an available research from Microsoft on the subject:

"Realizing quality improvement through test driven development: results and experiences of four industrial teams (2008)"

http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

[George Dinwiddie]

Robi, Marcus,

On 5/7/13 2:54 AM, robi y wrote:
> Not really...
> Here's an available research from Microsoft on the subject:
> "Realizing quality improvement through test driven development: results
> and experiences of four industrial teams (2008)"
> http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

For other such papers, see the list at
http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment

- George

> <http://martinfowler.com/bliki/TestDrivenDevelopment.html>).

>
> My question is: Assuming that TDD is a technique/style, what
> are the other existent techniques/styles available for
> proper comparison ? How about disciplines. is there a list
> of available development disciplines that I can query ? What
> are the other known and documented design techniques?
>
> On WikiPedia
> (http://en.wikipedia.org/wiki/Test-driven_development

> <http://en.wikipedia.org/wiki/Test-driven_development>), TDD

> is classified as a "Software Development Methodology" but in
> my humble opinion this is not accurate. The definition of
> software development methodology as described by Ian
> Sommervile in "Software Engineering" is: "... a set of
> structured approaches to software development which include
> system models, notations, rules, design advice and process
> guidance.". This definition seems to be appropriate for
> Software Development Life Cycle models such as Waterfall,
> Spiral and Scrum, but not TDD. Does that make sense?
>
> While thinking through this, I started thinking of TDD as a
> problem solving strategy but this is not clear enough for me.
>
> As always, thanks in advance!
>
>
> --
> Marcus Milanez
>