- ... FR I don t quite understand the argument. I just checked the curriculum of FR my former CS faculty and they offer seminars for MSc students on ExtremeMessage 1 of 37 , Jun 4, 2003View Source
>> Agreed Mike, the challenge - and there always is one - is how to makeFR> I don't quite understand the argument. I just checked the curriculum of
>> changes to the curricula of CS departments. Many decades ago I decided
>> I'd do a terminal master degree that my employer would pay for. Peter
>> Freeman was a "simple" Prof then (he's now the Chair of CS at George
>> Tech and does something in the government as well). We were learning
>> about analysis methods and had Al Irvine come to our work (aerospace
>> firm) from SADT fame. Peter had never really written software for money
>> before. Along with Standish (of UCI and data structures) I think they
>> learned a lot about the "commercial" world versus the "academic" world.
FR> my former CS faculty and they offer seminars for MSc students on Extreme
FR> Programming and seminars for BSc students on "modern software
FR> engineering methods".
FR> I remember half a decade ago :-) when I finished my degree PSP was very
FR> popular. We had seminars on that and research assistants were busy
FR> writing research papers on it. Now I'm seeing the same assistents write
FR> papers on test-driven development and pair programming.
FR> Generally, I find that Agile software development methods are much
FR> closer to how software is developed in an academic environment than more
FR> traditional methods.
When the first programming course in a CS curriculum uses Test Driven
Development, we'll be teaching programming as we should.
Sorry if that sounds dogmatic, but the mindset and habits formed are
just that important. The only reason I can imagine delaying the
teaching of that is so that people appreciate it after having coded
themselves into a hole a few times.
- ... From: Fabian Ritzmann [mailto:email@example.com] ... Oh, I don t know -- we are still sort of on topic. ... We call tests by the user acceptance tests orMessage 37 of 37 , Jun 6, 2003View Source-----Original Message-----
From: Fabian Ritzmann [mailto:usefri@...]
> Need to bring this back on topic for this list. :-)Oh, I don't know -- we are still sort of on topic.
> --- Fabian Ritzmann <usefri@...> wrote:We call tests by the user "acceptance tests" or ATs.
> XP as I understand it uses unit tests and system
> tests, unit tests for unit testing and system tests for
> whatever the users want to test, including quality
> aspects like performance, reliability, etc.
I think this is a valid definition across XP and
Scrum but I don't know if other agile methods call
them the same way.
> The combination is very powerful:Fabian wrote:
> * test as _specification_ from Test-First, and
> * program as executable _specification_ from
> functional programming
> Both strategies drive development more into the
> quantifiable _what_ space, much more than worthless
> "exhaustive requirements documents" or "models".
> Perhaps, this is what we need to concentrate in
> software architecture -- in patterns that tell us
> _what_ to program and that are executable,
>The principle problem is that provable (and executable)True. In our view, the need for acceptance tests
>specifications don't help if the specification is wrong.
>And we all know that specifications always change,
>that's why we do Scrum or another Agile development
>method. Of course that shouldn't keep anybody from
>improving the way we are programming these days.
conducted through people-2-people interaction
never goes away for the exact reasons you list
(and regardless the programming styles used):
- making sure that the specification is not wrong
- making sure that we keep up with changes
for the specification
- making sure that the user experience is
comfortable i.e. timely, convenient, beautiful, etc.
It is just easier, faster and even more economical
in some paradigms of programming to do the above