How many years of hands-on experience is enough?

I recently stumbled upon a question on linkedin.com regarding developers in India with over 10 years of experience. The question originator said that there is no such thing because anyone with over 10 years of experience has moved on from development to management or architecture. Another person said that anything over 5 years of development experience is just gravy.

I agree with the question originator, but completely disagree with the second person.

I personally have 18 years of hands-on experience. Over the course of 18 years I went from IBM midrange environments to Microsoft Client/Server to Unix/Linux Java based platforms. I held positions ranging from programmer analysts to development manager to CTO but I managed to stay hands-on because I love technology and I don’t believe an IT Executive can be a great leader and mentor without a solid hands-on foundation and a good mix of up-to-date knowledge of technologies, especially as a consultant.

I’ve interviewed hundreds of developers and so-called developers and for the most part anyone with 5 to 10 years of experience makes a much better developer then one with 3 to 5. What’s important in software development is the basic foundational knowledge of software development. Knowledge and solid experience with object-oriented design, distributed applications, web-enabled solutions, and databases make a better developer then experience with latest tools and frameworks. Recent tools and frameworks simplify developer’s life by letting him/her concentrate on coding business logic. This is great, but it also opens up a lot of potential problems. A developer who uses frameworks without understanding how those frameworks actually work is like a race car driver trying to drive a race car without knowing what it means to shift gears and when to actually do it.

The only way to get experience and knowledge of the fundamental design and practical skills one has to spend a number of years actually doing it. Therefore a developer who is promoted to an architect or technical manager after 3 years in the field usually fails to deliver quality solutions. On the other hand, someone with 10 years of hands-on experience is usually both a great developer and a good fit for technical management jobs.

Agile and offshore teams

I had an interesting conversation a couple of days ago regarding Agile methodologies, Scrum in particular, and how it can be applied on my current large software development project. I am managing a team of 17 developers, architects, qa, web and database folks on this project in 3 different locations, including 7 developers in India. The person who suggested the use of Scrum based methodology for our next project phase is a very senior developer/architect on my team. I personally like the approach but I don't think it will work for this particular project. Scrum or agile in general assumes certain level of experience and responsibility on a part of developer. It also assumes that people work in smaller teams and normally in a single location. There is no reporting hierarchy as such within an Agile team.

It is common knowledge that when dealing with large outsourcing provider, the client normally gets junior developers (1 to 3 years of experience) to do the actual work. Lack of experience and inability to make important decisions makes it difficult to go agile all the way. In addition, there is at least 2 layers of offshore managers/coordinators/micro managers who watch over the offshore developers. Agile will not work with such structure.

The way I look at it, agile is like having a swat team of highly experienced professionals who can work well together to deliver frequent quality results. Anyone with over 5 years of experience at an offshore company will move to a more managerial position unless they become independent consultants. From what I've seen with large offshore firms, it is impossible to put a team of developers together where each developer has at least 5 years of hands-on experience.

My conclusion is I won't attempt full agile approach when dealing with offshore teams. I will and do use partial agile approach on most of my projects though. I wrote about this in one of my previous posts.