TDD starting OO

[HS Thomas]

Is TDD going to be / a good starting point for learning OO ?
Could that be the first thing you start learning on an OO course ?
regards

[Lasse Koskela]

I wouldn't start learning OO with a TDD book. TDD doesn't teach you to think objects and too much stuff on the table makes it more difficult to learn what you're trying to learn.
Or maybe I'm just too conservative in my reasoning.

[HS Thomas]

That is reasonable advice.
regards

[Stan James]

TDD does force you to write testable code, which often encourages better designs - less coupled and less complex. It might be very cool to teach programming with unit tests as soon as you know enough syntax to make running tests. See Robert Martin's Craftsman Series about mentoring with unit tests.

[Lasse Koskela]

TDD does force you to write testable code, which often encourages better designs

TDD is supposed to reveal the best design for a class based on how the client wants to use the class, am I right? Isn't this a bit dangerous if the client, our procedural-thinking programmer, wants to use the class in a function library style?
I agree that TDD should be taught early but I still think it's not good to teach it *simultaneously* with object-oriented design. I'd be glad to hear about promising approaches to squashing these two flies at one stroke, though (I'm not teaching anyone but I think the industry would benefit from the large-scale deployment of TDD).

[Pradeep bhatt]

TTD?

[HS Thomas]

TDD
Test Driven Development
regards

[HS Thomas]

I think you should start teaching
1.OO concepts and principles first
2.then Design Patterns - real life examples
3.Next TDD with an OO language(Java, C#)
4.Followed by Design Patterns using OO language examples.
TDD is still evolving and is in it's early stages but the way things are moving it'll mature in about a year.
Pradeep, I should have added Kent Beck has written a book about the subject

Test Driven Development by example
If you really want to complicate your life and your loggo suggests you do,
try slotting Component Based Development, Aspect Orientated Programming
into the list above.

regards

[HS Thomas]

Stan , that's a nice link you have given there.
I can't decide who is more prolific - Scott Ambler or Robert Martin?
regards

[Lasse Koskela]

TDD is still evolving and is in it's early stages but the way things are moving it'll mature in about a year.

I would disagree a bit. I think TDD as a methodology has matured already -- Beck, Fowler, Wells, Cunningham, Jeffries and other early XP'ers were doing test-first development back in the day before 1997, I believe... (The infamous C3 project was launched during '97)
What's still a bit immature is the general community's fearful attitude towards test-driven development. People seem to really believe that you can't automate the testing of EJBs, web applications, and so on. We're on the right track, however, as the university folks around the globe get the hang of it and start pushing it early on.

Try slotting Component Based Development, Aspect Orientated Programming into the list above.

1.OO concepts and principles first
2.then Design Patterns - real life examples
3.Next TDD with an OO language(Java, C#)
4.Followed by Design Patterns using OO language examples.
5.Show the students how an existing application has cross-cutting concerns and how these clutter the otherwise clean OO-code. Then introduce AOP.
I think CBD should be left out of this course of ours because a) it is more of a software engineering and software product line engineering issue and requires pretty much insight to really get.

[HS Thomas]

I've just realised we have left out learning UML from the list ..
That wasn't a deliberate ommission, but a huge oversight!
I think it should be added either 2nd on the list or last on the list.
I think I'd prefer 2nd or even as 3rd after Design Patterns - real life examples.
May be the following book by Robert Martin may give a clue?
UML for Java Programmers
In Thomas Paul's reviews he does not recommend it for non-XP programmers and gives it a 2 star rating.
I agree with the view that a picture is worth more than a thousand words.
A UML checker seems to have one of the lowest pay rates, lower than a bog standard tester
So perhaps I'd put it last on the list?
regards
[ August 09, 2003: Message edited by: HS Thomas ]

[Frank Carver]

Personally I wouldn't put learning UML in a list like this.
UML is primarily a language for communicating some aspects of software designs to other people. As such there are lots of alternatives including all sorts of ad-hoc diagram techniques, code in a whole bunch of languages, speaking in your natural language of choice, handwaving, CRC cards etc. etc.
In my opinion, in a list of what to do to teach/learn O-O, UML is an optional thing to cover some while after basic O-O principles, along with extra languages, corporate "house styles" and "coding standards", specific editors/IDEs and so on.
There are a whole lot of good O-O designers and developers who never use UML.

[Lasse Koskela]

Personally I wouldn't put learning UML in a list like this.
...
In my opinion, in a list of what to do to teach/learn O-O, UML is an optional thing to cover some while after basic O-O principles, along with extra languages, corporate "house styles" and "coding standards", specific editors/IDEs and so on.

Design patterns would be difficult to present without a graphical notation and as such, UML would be the obvious choice. The necessary UML intro wouldn't need to be very in-depth. "This box represents a class. This arrow represents a specialization. Blah blah. That's it folks."

There are a whole lot of good O-O designers and developers who never use UML.

I would not declare myself being a good OO designer yet but I just thought I should share this... About 18 months ago I was on a project that lasted around 6 months from scratch to acceptance. I spent the first two months playing with MS Word and Rational Rose due to the client's standard BDUF process. I haven't touched Rose for more than 5 minutes since. Nowadays I sketch when needed. Much better.

[HS Thomas]

Hey, thanks.
So just enough UML to get going with Design Patterns.
An intro to UML just before Design Patterns with real life examples

1.OO concepts and principles first
2.then An Introduction to UML
3.then Design Patterns - real life examples
4.Next TDD with an OO language(Java, C#)
5.Followed by Design Patterns using OO language examples.
6.Show the students how an existing application has cross-cutting concerns and how these clutter the otherwise clean OO-code. Then introduce AOP.

regards
[ August 09, 2003: Message edited by: HS Thomas ]

[HS Thomas]

We're on the right track, however, as the university folks around the globe get the hang of it and start pushing it early on.

Does anybody know of any University that is actively doing this ?
I'd also be interested in Universities that go out of the way to teach
how to be innovative? I know, teach and innovative seem to be a contradiction in terms!

[Lasse Koskela]

Does anybody know of any University that is actively doing this ?

At least Helsinki University of Technology has been running courses talking about agile methods (among other things) and I suspect most universities abroad have done the same. I don't count this yet as "active" but today every single faculty member knows what XP is on a high level (more people seem to have heard of "XP" than "Agile", which is kind of twisted...). HUT has also been doing one project course in collaboration with industry representatives acting as clients where the student teams are required to follow XP by the book, I believe.

I'd also be interested in Universities that go out of the way to teach how to be innovative? I know, teach and innovative seem to be a contradiction in terms!

They need not be, though. Nobody can learn to innovate by reading a book but many people can learn to build an environment that nurtures innovation and thus indirectly helps to innovate. This has been on the agenda for at least a decade, though. Maybe not in tech but in business at least.

[David Weitzman]

I'd insert refactoring practice between design patterns and TDD. There's an alternation in TDD between coding and refactoring. If a person doesn't have any experience locating code smells or refactoring already-working code, TDD will be somewhat harder. Plus sometimes you can write code that you expect to refactor, and with that expectation in mind you can design it in a way that facilitates refactoring.

[Stan James]

Stan , that's a nice link you have given there.
I can't decide who is more prolific - Scott Ambler or Robert Martin?

Ambler may well have the most volume, but I'm pretty sure Uncle Bob has the most nourishment.
TDD has an appropriately eXtreme guideline: Don't write or change a line of code until you have a test that fails before and will pass after. I can't help but think that would be a great practice in learning or teaching any programming, starting with the second program. (The first program being the test that fails.) The first Hello World program should RETURN "Hello World" and get a green bar, not display it!

[HS Thomas]

posted by David Weitzman:
I'd insert refactoring practice between design patterns and TDD.

Thanks, that sounds very reasonable. I'd put it after TDD and learning an OO language as you cannot assume they'd have learnt to code if I put it before.
Just imagine it is iterative . So in weeks 1-5 you'd have run through the elementaries listed from 1 - 6. In weeks 6-10 you'd build on that with more advanced levels. A one year course should be more than sufficient to really get to grips , if you are writing tests and code all the time.

1.OO concepts and principles first
2.then An Introduction to UML
3.then Design Patterns - real life examples
4.Next TDD with an OO language(Java, C#)
5.Refactoring practice
6.Followed by Design Patterns using OO language examples.
7.Show the students how an existing application has cross-cutting concerns and how these clutter the otherwise clean OO-code. Then introduce AOP.


regards
[ August 12, 2003: Message edited by: HS Thomas ]

[HS Thomas]

This has been on the agenda for at least a decade, though. Maybe not in tech but in business at least.

Great ideas seem to ping-pong across businesses. One that I have been following Sentences originally started with IBM in the south of England, spent a period incubating at Synon and culminated (?) in Lazy Software.
Great ideas follow people around and interactions amongst people. Creating an environment that helps people innovate has been the raison d'etre of universities for centuries. Incubation periods used to be typically 30 years but that is now reduced dramatically with the advent of the internet.
regards
[ August 11, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Where would you include Pair Programming and how would you go about it ?
To me the natural place seems to be right at the start.
regards

[Lasse Koskela]

Where would you include Pair Programming and how would you go about it ? To me the natural place seems to be right at the start.

I agree. As soon as the students pick up the keyboard, there should be two sets of eyes and ears behind that keyboard.

[HS Thomas]

This is it.

1.Pair Programming and XP principles and values
2.OO concepts and principles first
3.then An Introduction to UML
4.then Design Patterns - real life examples
5.Next TDD with an OO language(Java, C#)
6.Refactoring practice
7.Followed by Design Patterns using OO language examples.
8.Show the students how an existing application has cross-cutting concerns and how these clutter the otherwise clean OO-code. Then introduce AOP.

I am not sure if this, in itself, would drive innovation but it seems a step in the right direction.
regards

[HS Thomas]

A word of the wise [ B Tate over in the EJB forum] suggests learning Anti-Patterns after learning good coding skills and before learning Patterns.

1.Pair Programming and XP principles and values
2.OO concepts and principles first
3.then An Introduction to UML
4.then Design Patterns - real life examples
5.Next TDD with an OO language(Java, C#)
6.Refactoring practice
7.Anti-Patterns
8.Followed by Design Patterns using OO language examples.
9.Show the students how an existing application has cross-cutting concerns and how these clutter the otherwise clean OO-code. Then introduce AOP.

regards