Non-technical question: Knowledge > experience or experience > knowledge?

Question

So I apologize if I'm posting this in the wrong place but I thought asking the coding crowd would be best.

So I'm building a website with 3 developers. One dev is on front-end, one on PHP back-end and one on the database design. The core application of the website is actually much more complicated than i/we (the devs here) originally imagined it would be. The hardest part is in the database design and the design and development of the CMS to manage the database. Working closely with one dev, we have created the final version of the database. This is good news. Meanwhile, the rest of the site is being built with Zend with the other 2 developers.

Essentially what has happened is that the database designer that I have been working with has all the knowledge in his head because he worked with me consistently to design the DB by learning about the technicalities of the domain, industry terminology, the system requirements and so forth. He has also designed the CMS to manage the products that we will insert as per his data structure. Logically, he should really be the one then to code the core application because he knows deeply what he designed. However our system is in PHP and he's a Java dev. So I'm pondering what do to. He has agreed that he could learn PHP in about 2-3 weeks he estimated but admits that at the start, coding would be quite slow while he falls over a few times.

The lead developer on the other hand knows little about the requirements of the core app, the design of the database, the products and the business domain and would therefore take a long time to go through the same process of transferring all this knowledge until he's intimately familiar with everything. So its really a question of time. Would it be faster for a 6 year Java dev to learn PHP and build the core app or would it be faster for the 6 year PHP dev to pick up the knowledge from myself and the database dev?

Is it a close call? Is there a clear winner?

Any advice/suggestions? Thanks

Answer 1

I would vote for using the experienced PHP dev rather than one new to PHP. Any experienced PHP dev should be able to take a brief from you and your colleague on what is needed and utilise the db design work already done.

A dev new to PHP will not produce code that is as well written as an experienced dev and that could cause you problems in the future.

The other solution would be to use Java for this application even if some of your other apps are PHP based. The two can live pretty well side by side.

Answer 2

In essence I think that having experience of design and a good knowledge of how systems work is the most important thing.

Individual languages can be learned (and yes, there is a learning curve, while the syntax is absorbed, then the idioms, etc) and whilst having someone who knows a language when they start makes them a little quicker off the mark, I would choose someone with good design skills over someone with weaker design, but more knowledge of the language.

Language skills can be learned much more quickly than design principles.

In your situation, you have a problem. Two good people with different skillsets. Surely the ideal solution (if it's financially viable) is to have them work as team. Then both will learn much more quickly from the other where they are weak - and they'll be able to discuss design issues and rational. You should end up with a vastly superior product, and two developers whith enhanced skillsets and expanded experience. A win-win, if they can work well togther.

Answer 3

I'd vote for the PHP-dev, working alongside the database/java dev. That way, the database/java dev begins to get exposure to PHP, which will help his learning curve; while the PHP-dev will pick up the database structure and the all-important business rationale/details from the database/java dev.

You shouldn't create a dependency on any one person if you can help it, but distribute the application knowledge across your team. This way, you'll end up with a stronger team overall.

You should also ensure that the knowledge isn't maintained purely in anybodys head, but is documented. Always consider the dangers of a number 17 bus when all the knowledge is in somebody's head.

Answer 4

I agree with @Ragster - get the database guy and the UI guy to work together. There's even a buzzword for this - it is called pair programming.

But I'd add one thing. It sounds like a significant part of the problem is that the database guy has all of the knowledge in his head ... and there is nothing written down. This is not good. What happens if the database guy is run over by a green bus?

Maybe you need to make the database guy's number one priority to document the database design in a form that the UI guy can assimilate.

Answer 5

The nature of your question implies that you expect your programmers to develop in single-user mode throughout. I have honestly never met a situation where that was less appropriate than for you right now. Allow/instruct the obvious candidates to use pair programming, and the problem will simply dissolve into thin air. You will get better understanding within the team, faster results, better code, more unified solutions all around...

I am not being flippant here. If you have any historical or even ideological aversions to pair programming, please please please try to just get over them. It just is that much more efficient.