[TIP] testing: why bother?

C. Titus Brown ctb at msu.edu
Wed Mar 23 14:16:27 PDT 2011


On Wed, Mar 23, 2011 at 04:58:04PM +0000, Michael Foord wrote:
> On 23/03/2011 16:40, C. Titus Brown wrote:
>> On Wed, Mar 23, 2011 at 04:26:02PM +0000, Michael Foord wrote:
>>> On 23/03/2011 15:37, C. Titus Brown wrote:
>>>> [snip...]
>>>> Also I don't know of any actual evidence that TDD or agile actually improves
>>>> programming speed, ability, thought, or anything else, over other methods of
>>>> specification (more formal ones, for example).  Anecdotes need not apply.
>>>>
>>> Well sure, but unless you have evidence to the contrary (anecdotes need
>>> not apply) that's entirely moot.
>> This is an ... interesting opinion, actually.  If you're dealing with
>> institutional inertia -- working within a large team, or on educational
>> curricula -- then *positive* evidence is needed to effect a shift.
>> It may not be sufficient, but it's certainly necessary.
>
> Here's some anecdotal evidence that you should definitely ignore. At  
> Resolver Systems we would (I say would because I no longer work there  
> and can't speak as to their experiences for the last year or more) hire  
> two interns every summer. Intern applicants were typically  
> undergraduates and came from all over the world, including the most  
> prestigious universities in the UK.
>
> In interviewing it was striking that many of the Polish applicants were  
> head and shoulders above the others because they had learned (horror of  
> horrors) practices like testing and version control and had participated  
> in group projects using them. Their teaching had been *relevant* and  
> *useful* for real world programming. Certainly not what one expects from  
> a typical university education. ;-)
>
> For the three summers I was there we had six interns, five of them Polish.

I believe it.

I'm not sure this is the best place to discuss this, so I won't in detail,
but:

CSE departments have several conflicting goals, which include educating
people in software engineering, along with data structures and algorithms,
computer graphics, graph theory, math logic and discrete math, formal
design, bioinformatics, hardware, high-performance computing, computer
languages and language design, compilers, and lots of other stuff that
I don't know much about.  I think we (MSU) could do a *great* job of
educating people in software engineering if we really wanted to, but
we instead try to provide a core (basic programming chops, discrete math, and
data structures and algorithms) surrounded by a bunch of electives -- and
software engineering suffers as a result.

It's also really hard to find good young faculty who haven't vanished to
industry, since a lot of REALLY interesting CS problems are cropping up
in industry.  Raise your hand if you think Hilary Mason would be an
awesome prof to teach programming... yeah, right, and she's at bit.ly
instead of at a university, you may have noticed ;)

I'm not saying this to defend MSU, which is doing a fine if fairly typical
job of CS undergrad education, but more to point out the inherent challenges
in teaching *practical* programming along with all the other CS topics.

And now you say what?  You want us to change our carefully developed and
set-in-stone curriculum to teach in a newfangled way? Bah, humbug!

On a related note, some people at PyCon approached me about starting up a
CSE-SIG that I imagine would discuss this kind of stuff more specifically.
Seems like a good idea... it's on my list.  I'll send out a note when I
do something on it.

cheers,
--titus
-- 
C. Titus Brown, ctb at msu.edu



More information about the testing-in-python mailing list