Skip to main content

Development Philosophy : Development and Teams


Warning: Rant about what is in my head and random opinions to follow.

I have seen a few posts on sites disparaging developers from various nations but from my perspective I understand this but don’t agree with it. First off if you pay peanuts you get monkeys (do monkeys really like peanuts who comes up with these sayings) if you pay top dollar generally besides the charlatans you can get the best people no matter what country you are in. I have worked with awesome developers from a lot of countries but as a general rule developers tend to be crap and under-trained (by my standards) because the pervading philosophy of the day is cheap is better. I think every nation produces a small set of highly skilled developers and then the average ones. Most of those great developers have been hit by the peter principal and are no longer developers. I don’t know many great developer who are not non coding architects, development mangers etc. (Let’s start creating hero’s in every role please)

I have had the privilege of working with what I consider an uber team – well paid developers who have a passion and love developing where the company spares no expense(Nerdvana). This is an awesome experience that I suggest all developer have once in their lives because the experience is rare but fulfilling. That being said the general rule here is one or two experienced developers and a team of younger developers. This works well and I suppose is the most cost effective option but you hit a snag if one of your superstars leaves. (all great developers have their own style and you are likely to get a rewrite proposal with any new one).

I am beginning to think about the throw away system approach as an effective tool – a system with a 5 year life cycle (or when the maintenance becomes too costly). After the life cycle you redo the system in a parallel stream the downfalls of this is as you rewrite the current system changes and you have a moving target.

There must be a fair way to make sure you are getting a developer who can perform but I can’t think of something besides bad ideas [Rating system, Developer clubs, Linked in recommendations] (remember that developers all have different strengths and weaknesses so a mix of these can go a long way to a well rounded team)

Uber team – A small team of ultra experienced developers
Pros – You will have a great system, built quickly by people who know what they are doing.
Cons – There will be blood, clash of opinions and egos will be rife. Hard to focus, some developers find it hard not to create the perfect system instead of delivering. Hard to get the right balance and people.
To make this work you will need to put one person in charge and give them the power of veto or will have to lay down a framework for them to work within.

Few good men team – One or two very good developers and a team of average/ cheap/ young  
Pros – Cost effective, great hand over, growing the next generation.
Cons – Key man risk, experienced developers don’t like to share or work with idiots. Also you could end up with one or two people doing all the work.
To make this work you will need to get the key men and have a plan for when the things change. You will also have to look after your developers as the key man will have a burden of work.

Outsource developer team – Highly skilled outsource manager (technically brilliant and good with reviews and management a rare find indeed may need to split this into two people) and a team of outsource developers.
Pros – Perceived cheap, company gets to focus on their core business, no lack of resources and hr issues.
Cons – Language, process heavy, requirements need to be exacting.
To make this work – Get the right outsource partner and manager, VERY rigid process.

How to hire the best – to do this you need the best and need to not be shy about cost. In South Africa the best of developers are generally contractors. I think it is quite near to impossible to hire a developer without a highly skilled person to interview or word of mouth. Things to look for are passion, experience, track record, interests. Someone with passion will go out of the bounds of what they are currently doing to find out what the world is doing. Also generally there are a strong set of opinions that come with strong developers. But with what I have said there are just generalizations so you will have corner cases.


Whatever road you choose you will have to get the pattern right and the correct people. Good luck.

Comments

Popular posts from this blog

ADF Encountered deferred syntax #{ in template text.

OracleJSP error: oracle.jsp.parse.JspParseException:  Error: Encountered deferred syntax #{ in template text.  If intended as a literal, escape it or set directive  deferredSyntaxAllowedAsLiteral This normally happens when you have some tag lib dependancy problems but this was  not the case for me... My problem: For some reason my model project had web stuff in it(public html etc)  so I had to remove the public html stuff from my project and manually edit the Model.jpr project file and remove the tag lib entries at the bottom o the file. Go figure.    

JBO-25013: TooManyObjectsException

oracle.jbo.TooManyObjectsException: JBO-25013: Too many objects match the primary key oracle.jbo.Key[Key null ]. Ok so for you it may be trying to insert a duplicate record this should explain your problem (also check trigger they could be the cause.) NOTE: You can also try to create a new duplicate EO if you have a page with two VO's using the same EO. This could sort your problems. For me I needed to add a launch listener on my LOV and clear the cache of my vo. LOV <af:inputListOfValues id="NameId" popupTitle="#{bindings.Name.hints.label}" value="#{bindings.RolName1.inputValue}" label="#{bindings.RolName1.hints.label}" model="#{bindings.RolName1.listOfValuesModel}" required="#{bindings.RolName1.hints.mandatory}" columns="#{bindings.RolName1.hints.displayWidth}" shortDesc="#{bindings.RolName1.hints.tooltip}" launchPopupListener="#{backingBeanScope.backingBean.launchPop

MANIFEST.MF merge JDeveloper for an executable jar

Goto your project > properties. Then click on deployment in the menu. Edit or add a jar deployment profile. Fill in the details under jar options (select Include manifest and give it a main class name) Also remember that the merge functionality only works with a BLANK line at the end of the merge file. REALLY this caught me. My merge file contents: Class-Path: commons-codec-1.3.jar [...empty line here CRLF...]