Learning Curve Development Time Question

[Zach Dennis]

I am curious what others have found with a learning and development curve
with areas of code that are quite similar.

In the design of a small scale project there will be 2 main systems. Inside
of these systems will be a few more smaller subsystems. The systems will
communicate to eachother via network socket interfaces. This is so we can
have the systems to different machines. I was thinking for expandability
purposes that perhaps we made the subsystems work the same way. So that if
for any reason we found one area getting used a ton that we could move it to
it's own machine with little effort. Since the 2 main systems would need
socket interfaces to communicate with eachother I am curious if coding the
subsystems would provide unneccessary development time. Or if since the same
logic could be applied that was already coded and tested in the 2 main
systems that the development time may not be unneccessary.

In any of your experiences is this the case? Would the development time for
the subsystems go way down since the main 2 systems have been tested and is
good to go? Or since they are different "systems" would the
learning/development curve still be just as steep?

Thanks for any replies!

Zach

 

[Rove Monteux]

Not sure if its inside the topic at all, nor if it will help, posting
the testimony anyway.

All of our internal software, most automation tasks, content management,
in others, used to be coded in Java, few (very few) on Perl.

Platform used to be Win32 and solaris on x86, more recently we have
moved 90% of it to OpenBSD on x86.

Id honestly say, the first reason to move away from Java was the lack of
support on OpenBSD. Then came the Perl phase.

Honestly saying, we are programming in 1/2 days with Ruby, what we used
to take 1/2 weeks in Java.

Specially the simplicity, and the builtin methods for web, ftp, email
and regexp are the obvious reasons for that.

Not sepcialist in Ruby yet, altho the learning curve for doing the same
software has been considerably low, as we did java and perl before.

One thing we notice is slightly harder to track programming errors, it
took a while to get used to it. But overally, its been well worth it, if
we were able to deploy the same code to the Java VM, that would seal it.

Still portable tho, and runs pretty much in everything.

Again not sure if any usefull on the case, but there it is.

Good luck !

Rove Monteux

 

[Peter Hickman]

I am curious what others have found with a learning and development curve
with areas of code that are quite similar.

In the design of a small scale project there will be 2 main systems. Inside
of these systems will be a few more smaller subsystems. The systems will
communicate to eachother via network socket interfaces. This is so we can
have the systems to different machines. I was thinking for expandability
purposes that perhaps we made the subsystems work the same way. So that if
for any reason we found one area getting used a ton that we could move it to
it's own machine with little effort. Since the 2 main systems would need
socket interfaces to communicate with eachother I am curious if coding the
subsystems would provide unneccessary development time. Or if since the same
logic could be applied that was already coded and tested in the 2 main
systems that the development time may not be unneccessary.

In any of your experiences is this the case? Would the development time for
the subsystems go way down since the main 2 systems have been tested and is
good to go? Or since they are different "systems" would the
learning/development curve still be just as steep?

Thanks for any replies!

Zach

Having two systems talk across a network is not to big a deal but at
what level do they need to communicate. Could the whole socket thing be
replaced by http requests? This would allow you to step back from socket
programming and use things like Webrick.

Just a thought.

 

[Jim Weirich]

Peter Hickman said:

Having two systems talk across a network is not to big a deal but at
what level do they need to communicate. Could the whole socket thing be
replaced by http requests? This would allow you to step back from socket
programming and use things like Webrick.

Or even something like DRuby!