Application virtualization with xenocode
July 14, 2008
Application is the future of virtualization. Xenocode allows you to package up an application and deploy it in a virtaul exe to run anywhere, (anywhere on windows). I came across it when I wanted to create a portable application using the ,net framework. Xenocode is amazing. It allowed me to package up a winform application written in C# to produce a stand alone exe that could run on any windows box even without the .net framework installed. I have not tried it under wine/linux but it is on my todo list.
While we have yet to use it in a project think how easy a deployment process will be when have xcopy deployment without any need for a framework to be installed on the destination machine.
So for all you .net coders out there start pumping out the usb portable apps with visual studio.
turn your dotnet exe into a portable usb app
Subversion
July 14, 2008
Subversion is our prefered tool for version control. With the latest version you have merge tracking and can compare history of word and excel documents, (when using the tortisesvn client). With this new functionality I can see it being our document management system as well. It is fast, easy to set up and transactional, (commits all your changes or none at all unlike pvcs). As a added bonus it is opensource and free to use.
There are many clients for subversion the two we prefer are
http://tortoisesvn.tigris.org/
This is one of the core bits of software you want running on day one of a project. We had a architecture team try to force us to use pvcs which is non transactional and pay for the privilege. What a step backwards that would have been. It was only that we had it running in our build process from day one that stopped this happening. It was a bit of a lesson for me, if you want your key bits of technology supporting the development process have them running on day one. I wish we did the same with our bug tracking tool. Unfortunately we were forced to use trackrecord which I would not recommend to anyone, (especially when there are some many excellent open source bug tracking tools).
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.
