The New Developer
July 14, 2008
We believe that when a new developer starts work in our team they should be able to start work on real project tasks by lunch. To achieve this you need a number of things to be in place namely
- A Buildprocess
- Automated unit testing
- Developers virtual image
- Project tasks that can be allocated to a new developer
- A developer allocated to pair with the new developer in the initial stages.
Added to this we have a number concepts to keep in mind
Developers are drip fed into the team. New developers should be assimilated into the team one or two at a time. This is to avoid old school or negative views around the benefit of automated builds and unit testing. By having one or two developers come in at a time it is easy to get them coding and testing the way we want.
Egoless programming. By this we mean no developer owns a specific piece of code and you should always be able to listen to a different view. Don’t be defensive when someone when someone offers a different approach to something. I have met very few developers I could not learn something from, (they do exist but usually will not fit into ego less programming because they have big ego’s).
Everyone is Expendable. If you find someone in your team that can not be replaced easily start to arrange so their knowledge gets shared around. The reality of the IT industry is people change jobs all the time. The culture we have built up in our team has kept this to a minimum as everyone enjoys the success and development processes we follow. From a management point of view we have done a good job if on any given day we can loose an experienced resource and the team keeps working as usual. Having one person own a price of code can have disastrous results. If one person is left to be the only developer on a piece of the application they generally fall back to their core skills to solve a problem. A recent example we encountered was when we inherited an etl process. We had no influence over the development and were lead to believe that ssis was used to implement it as prescribed by the project architecture. After we looked at the code we soon realized that just about all of the etl was implemented in tsql which was the developers primary skill. All the out of the box functionality which makes ssis a useful etl tool was ignored as it was not in the skill set of the developer. This left us with a very complex solution to something that should have been a lot easier if it was implemented by someone with ssis experience. In the end we had to make the call to rewrite the etl layer using ssis functionality and keeping the design simple.
Be wary of people who tell you they are an architect every chance they get. While some architects are worth their weight in gold they are few and far between. Make sure you check out their cv references through people you know instead of who is on their cv. I onced asked a architect who was running a data warehouse project if their database was a typical data warehouse schema expecting something like start or snowflake schema but got “Yes third normal form”.
Application support should be involved in the development process. Instead of getting new resourses it is better to get application support staff involved in the development process. How better way to ensure your legacy of automated builds and deploys will be continued when the project moves into the application support phase.
Keep It Simple. Every project is a battle to keep technology decisions simple. I have worked on very few large projects that have not been over engineered to some degree. You are always battling architecture groups, enterprise teams, empire builders and people who can talk well in meetings but are light on technical ability to implement a simple solution. You loose your fair share of these battles due to political influences. The only thing you can do in this case is to make sure you have a review at the end of the development cycle where you point out to upper management how a simple job was made complex to the detriment of the project. If you can hire someone off the street with 2+ years experience, they can sit down and understand your code, maintain it and deploy changes to production you have done your job.
So when a new developer arrives on site what happens first. During their first hour
- They meet the team during our morning 10 minute scrum. During the meeting they are assign a task.
- We pair a developer with them
- They copy our developers vmware image to their computer
- Start the developers image
- Run a script to personalise the image
- Start our build process and run the local clean step. This will download the latest databases, code and binaries that successfuly built on the build machine, (compiled and pasted unit tests).
The developer now has everything they need to complete their task and become a valued contributor to the team in no time at all.
Comments
Got something to say?

