tags:

views:

77

answers:

5

How to deal with the fact that you don't know the language/framework in a development process?

For instance, suppose a group of Java developers are about to start a .NET project, they don't know the platform well and might end up finding solutions that the framework already solves or solves better.

The sort of questions I have are: which are the best practices in this case? Is RTFM before going on a good pratice? When should one stop RTFM and start asking/searching/playing? Is not RTFM and just searching/asking/playing a good practice? What about estimates?

I'd like to hear from your experience :-)

A: 

What about some sort of code-review or related step where some experienced person could glance through and offer suggestions.

RTFM seems like it would just waste time, especially if you are doing agile development.

EDIT: Since you said 'nobody' in the team knows the language... I don't know, but RTFM still seems like a waste of time to try and 'learn the whole language' before you start.

webdestroya
Of course, he says nobody on the team has experience with the toolset/technology.
Tom Cabanski
Ah, my bad. I updated my post to reflect.
webdestroya
+4  A: 

Learn the platform before writing production code!

Often people just jump in and start writing their app, and it becomes a mess, the developers learn lots then regret the "noob" stuff they did, but are locked in.

So my theory is take a few spikes and go throughan implement a very very thin feature that goes through all layers of a framework.

ie, say if it was a web mvc / web services..... something that has javascript - > ajax -> html -> web service -> Controller -> Model -> Database.

Get people to review it. Don't spend time building a framework layer when you don't know a lot about the Technology you are dealing with. Spend some time exploring what kind of flexibility your technology has (ie, try a number of different ways you can skin a cat)

Keith Nicholas
+2  A: 

Hands-on learning effort will beat RTFM almost every time assuming you have a team of skilled developers and the new technology is somewhat equivalent to what the team has historically done. For example, I could see undertaking .NET web development with a bunch of Java web developers, but I would not be very comfortable undertaking .NET web development with a team that has been focused on VB Windows applications. You should start with spikes of basic functionality that span all layers. Best practice would be to add an expert or two to the team to help mentor and guide the development process via pair programming. For estimating purposes, I would significantly reduce the number of story points I would allow the team to undertake in the first few iterations. Conservatively, I would plan on achieving no more than half the team's historical velocity in the first few iterations.

Tom Cabanski
I agree with the expert part, if it is possible it is totally worth hiring someone experience to accelerate the learning. But what if it isn't?
Thiago
+2  A: 

I think, as well as other, that it is important to have a good mental model and to understand abstractions you will use... However, sometimes it is not as easy, maybe because of insufficient time, experience or even documentation. You can get some thoughts here: http://www.se-radio.net/podcast/2009-06/episode-138-learning-part-development-allan-kelly There is also an agile methodology which takes learning as its strategic part: Adaptive Software Development (ASD) http://en.wikipedia.org/wiki/Adaptive_Software_Development Lastly, I want to mention exploratory tests in Test Driven Development, which can help with learning new frameworks http://en.wikipedia.org/wiki/Exploratory_testing .

Gabriel Ščerbák
Thanks for the references! I agree with the importance of mental models and understanding of abstractions, but these may be different and learning them (and to combine them) takes time. One simple example is the dependencies and bindings on WPF, which I'm struggling right now in one project.
Thiago
A: 

Most of the teams I've been on have had at least one language enthusiast. These guys love to learn everything they can about new languages and are more than happy to share. Figure out who this person is on your team and let them know that you're going to be working with the new language.

Once you start, do code reviews. Lots of them on small, manageable pieces of code. The code enthusiast will be able to point out things that are handled better by the language. The whole team learns this way.

jfawcett