Well, I’m a senior developer/team leader. I have been considering
moving
the team from “c” to ruby. However I have doubts that the
lower-level
programmers can handle development without any type-checking
support. So
we will probably move to either Java or c#.
What do you think you need to protect them /from/, exactly?
No, it’s more to protect me!
It’s to protect me from questions like:
“Hey, what kind of object is this method expecting? It isn’t documented
anywhere and I can’t understand the source code”.
“Hey, I’m getting this message from the XXX library about do_foo not
existing on parameter bar. I must be doing something wrong. How do I fix
it?”
“Hey, I’m supposed to fix this library method. What parameters are
people allowed to pass to it?”
and the corollary question:
“Hey, your team isn’t making much progress on this project, despite this
Ruby language you suggested. Why shouldn’t I fire you?”
On Thu, 2003-11-20 at 15:54, Michael Campbell wrote:
Well, I’m a senior developer/team leader. I have been considering
moving
the team from “c” to ruby. However I have doubts that the
lower-level
programmers can handle development without any type-checking
support. So
we will probably move to either Java or c#.What do you think you need to protect them /from/, exactly?
Simon Kitching wrote:
Well, I’m a senior developer/team leader. I have been
considering moving the team from “c” to ruby. However I have
doubts that the lower-level programmers can handle development
without any type-checking support. So we will probably move to
either Java or c#.
What do you think you need to protect them /from/, exactly?
No, it’s more to protect me!
There are alternative mechanisms for doing that, though.
It’s to protect me from questions like:
“Hey, what kind of object is this method expecting? It isn’t
documented anywhere and I can’t understand the source code”.“Hey, I’m getting this message from the XXX library about do_foo
not existing on parameter bar. I must be doing something wrong.
How do I fix it?”
If this is in a core or extension library, this is a problem. If,
however, it’s in a library written by your team, this is a huge
problem. Some of this could be fixed by tests.
“Hey, I’m supposed to fix this library method. What parameters are
people allowed to pass to it?”
Where’s the design document? Where’s the test cases? Why isn’t the
library method documented in the first place?
and the corollary question:
“Hey, your team isn’t making much progress on this project,
despite this Ruby language you suggested. Why shouldn’t I fire
you?”
I think that’s an unnecessary fear. Honestly.
-austin
On Thu, 20 Nov 2003 14:40:04 +0900, Simon Kitching wrote:
On Thu, 2003-11-20 at 15:54, Michael Campbell wrote:
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
* 01.22.39