views:

1192

answers:

25

Have you got any best practices when starting to work on a project using technology or a language you have never worked with before ?

Do you just go ahead with what you know and get to learn more as obstacles come or do you have any prerequisite steps you always go through ?

The question is in fact what additional measures would you take compared to working on a well-known subject.

EDIT: And on a management point of view how would you handle that case ?

  • How do you estimate the time of the project ?
  • Do you prefer assigning experienced programmer (more awkward project) or do you prefer assigning younger ones (whoever it will be they'll have to learn anyway)?

Still the same question really do you handle these projects differently ?

+3  A: 

Always, always read the equivalent "Hello world" tutorials and move on from there.

Ngu Soon Hui
This should be the first thing you do! Then move on to a "pet" project you are familiar with. Once you become familiar with the new technology then you start working on your project.
Brian T Hannan
+1  A: 

In my previous job, we have book library.

Whenever we got new project with new langauge or technology, we just go there and took some books and start testing those step by step.

S.Mark
+1  A: 

I try to read up on the subject at hand. Peek at what ever other solutions that are available (cause let's face it, how often has it not been done before?). I also try to experiment a bit with the technology if possible.

mett
+2  A: 

For me the important thing to remember is that you don't have to know it all at once.

I start looking at small bits till I understand them - then look at larger pieces.

I also look at the big picture - then I go into more detail.

At a certain moment, the two should meet (I hope!), and it all falls into place.

My normal approach is to start working on small parts of a system in order to gain understanding - as I work on it and interact with other parts I learn more and more. This is true for using a new technology, start with the basics and then move on.

Oded
+10  A: 

I always keep a notepad handy.

For each day that I'm using the new language/framework/API I'll put that day's date as a header. And under that I'll make a note of any interesting quirks I've seen that day. The reason being is that I find it I'll often have to revisit something two or three times before it gets ingrained in my mind. Having notes to refer back to is a major help.

mmccomb
+1 for avoiding the mistake : "I've seen it, I know it" :p
DrDro
I am finding notebooks to linear, so I have been experimenting with locally hosted Wiki's.
Peter M
+3  A: 

I usually approach this on two fronts, in parallel.

  1. Read some good/recommended tutorial or book on the subject.
  2. Start implementing small functionality snippets relevant to your application/project, from the bottom up, in this new language & technology. This is "exploratory programming", you will use lots of Googling here, and read some code written by others to understand how things work

Having two in parallel means you will benefit both from the theoretical and the practical, and will be less bored. Neither can be skipped, IMHO. Many rush to the code without reading up, and it usually results in bad non-idiomatic code.

Eli Bendersky
A: 
  • Books
  • Internet Research (Specifially targeting your project)
  • Take Notes
  • Use colleagues knowledge (if availavle)
  • Create a couple of small projects to test out different ideas/examples
kevchadders
+1  A: 

Same way as I'd start a project in a language I already know, except the manual would be slightly closer.

Noon Silk
+2  A: 

I have recently started a new project using Wicket and postgreSQL. both of which I've never used before.

I would strongly recommend that as soon as you have mastered the basics, if you have any interaction with other technologies (such as DB), try practising integrating to them as well. It's guaranteed that you will find challenges there as well.

It's better for you to solve these challenges at the beginning so that you know what you will facing and can plan around it than later on in your project, when significant changes might be needed.

Lucas T
+12  A: 

Most cases, I just write a program that I have written in other languages and which does not give me a headache from a conceptual perspective. For me it's a neural network, others use easy raytracers or whatever.

You then see what's difficult about the language and where things are different from what you know. Just don't start with the actual project right away.

bayer
+5  A: 

Normally, you first research whether this technology suits your project at all.

If it does, you go ahead and start the project, getting through obstacles as you go.

The most important here is to define the potential problematic cases, the doubts you have about the technology and resolve them with the priority one. Whether it can interface with another technology, whether it supports some protocol, whether you can implement your desired architecture with it, whether it is performant enough in certain cases. The idea is to identify first whether a ship (your product) can move at all before you start polishing the hull, so that you don't invest too much time and effort in something that may not work out in the end.

Speaking of prerequisite steps, it may be advised to look for stories of equivalent projects completed with this technology. Projects with comparable complexity/size, overall architecture, implementation of specific things you'd want to have. This should give you an idea what can and what cannot be done.

Developer Art
+3  A: 

Practicing first with "hello world" tutorial is a very good starting point.

Moreover, in order to get most of it, I always try to answer the question: Why is it done this way and not that way?

My goal is to get the philosophy behind the technology, to find out the big picture and the intention of the creator, i.e., what problem its technology solves.

mouviciel
+2  A: 

I would say It mostly goest this way:

  • read the how to / forums / ...
  • solve the problem (after all this is probably why you are using something you don't know)
  • after some time and knowledge accumulated ... REFACTOR / REWRITE your original code
Drejc
I'm wondering about your last point. Isn't there a risk you spend your life rewriting some old code ?
DrDro
i agree, good point :)
asdf
No it isn't if you are not refacroting once in a while you get stuck with some ugly code you have written when you didn't know all what you know now. But of course you need to make sure you have unit tests in place to cover your bases.
Drejc
+5  A: 

I start a new Google Docs document called "XXXX Bible" where XXXX is the new tech in question. Then every little hurdle or trick or gotcha goes into that.

Alan B
+1 on the documentation. I'm trying to do a similar thing but with a blog as my documentation weapon of choice, just makes it easier to share
James.Elsey
+1  A: 

The best single piece of advice I can give you is problem domain. Is the technology right for the problem you are trying to solve?

If it has been answered and the answer is yes.

  1. Take notes, which was mentioned before.
  2. Watch videos, I tend to learn a lot easier when seeing and understanding what the person is doing.
  3. Have the documentation handy.
PieterG
+1  A: 

Maybe this is slightly out of scope but:

  1. You should decide about your development process, which is fairly language independent.

  2. This will include how your testing will be done as well

  3. You need to look at the best practices from the person who are well known in this technology (for code, it can be to look at coding practices from well-known open source projects)

  4. Try to find some highly recommended books and having high ratings in electronic bookstores

  5. Email and contact the persons who are well known in this field and who left their emails on some project page, you will be surprised by the number of people who take time to reply to your emails when you ask them advice politely.

Try to not be lost too deeply in implementation/tool-dependent issues when it is not critical, and adopt the best practices and conventions early when you start using a new technology would be my advice.

Anthony

BlueTrin
+19  A: 

My preferred approach to technology evaluation is to use the following steps:

  • identify the must have features Decide what are the most important features that you need from the technology. This forms your acceptance criteria.

  • Research the technology to get a first impression. You are looking for info such as cost, community adoption, maturity, features, licensing issues, compatibility with your existing software

  • Do a relative comparison. Identify a small "pet" application that you know inside out. The advantage of this is that you don't have to think about requirements, and you have implemented it before using technologies that you already understand. Choose an "pet" application that hits the main implementation points of your typical projects. E.g. You will see many web application developers implement a simple blogging engine as a way of evaluating or demonstrating a technology. Twitter clients have also been all the rage recently.

  • Avoid distractions The key to an effective evaluation is to be focused and not allow yourself to be bogged down with peripheral issues. E.g. do not be concerned with the CSS layout of the GUI if your evaluation task is to look at a web framework. Sometimes it is best to timebox evaluation tasks in order to force yourself to focus on what you can realistically achieve.

Paul
Many interesting points in different answers so, again, i've chosen the one with the top votes.
DrDro
A: 

To read and learn something is not a good way. Any you tend to forget what you read. So me i always start with a small program something like a hello world and give myself a 'Good Boy' pat on the shoulder just for a boost.
Then start looking up blogs and read of practices other gurus have discovered the hard way round. And make a note of it in a notepad under the name of the technology or language. Also write a short one line on why is the link saved so that i can return back if needed. Also put a star after the one liner if its something related to the project that i have to start.
The next step will be to setup a base project start with the job on hand. In between refer the language doc as much as possible so that i will be reading and trying out things.

zapping
A: 

For me always the Trial and Error approach worked well. I do read some basic information on the new language / technology but after that unless I get my hands and feet wet in the technology I don't usually learn much. I am not sure if its a good practice but that's how i learn.

Even if the company does not adopt the new technology, I would have learnt a new language. Of course this might not be the way management wants you to approach things.

vikramjb
+1  A: 

If you need to learn multiple new technologies (for example at the moment I am learning Entity Framework + ASP.Net MVC 2) then I suggest creating end-to-end reference implementation. Try to find best way to create it and then "copy" this reference to other areas of the program / website etc.

Tx3
+1  A: 

I would start by questioning whether using a new technology or language is a good idea. Sometimes it can seem very important to use the latest tech on a project you have high hopes for. Often when I have been seduced like this, I have found that the latest shiny thing is just as flawed as the tech I already knew.

In many cases, if you really care about the project, it is better to stick with what you already know.

UpTheCreek
+2  A: 

Allow lots of extra time!

You will always make mistakes witout realising it - rather than spending lots of time pre-emptively trying to avoid the mistakes that you don't even know why they are mistakes yet, just accept that you will make mistakes and allow time to go back and fix them.

Kragen
A: 

when it comes to languages, there's one thing I can say:

if using the language is actually worth it, than all the code you'll write within the first 6 months is gonna be crap, measured by what the language can do ... there's an important rule to adhere to: do not try to use the idioms you know from elsewhere in that new language, and complain if the language doesn't support it ... rather try to get an overview of the language's special features and prevalent idioms, and try to focus on expressing solutions using those ... try new approaches promoted by that language ... otherwise you choice to switch languages is pointless ...

greetz

back2dos

back2dos
A: 

Do spikes as needed to understand the new technology. These can be done as learning tests (unit tests) to preserve the knowledge.

TrueWill
A: 

When trying to learn a new language, I would recommend lurking on IRC. Many of the major languages and technologies have channels on freenode and simply watching what people are talking about is a great way to find out about the aspects which you might not have even considered when doing your own reading of a tutorial or book on the subject.

Of course IRC will be a great place to ask questions when you start to run into obstacles, however I recommend putting all those questions down on paper and leave them while doing more research. It often takes a while for those unfamiliar terms and syntax to slot into place in your brain and being able to go back and cross off, or re-evaluate any previous concerns you had I find very useful.

Alex Spurling