Most of the projects we start from scratch; we usually start with a build time of less than 2 minutes with all the unit tests, code analysis metrics and reports. If you have heard about the parable of the boiling frog, then something similar happens over the course of few months when the code has gradually grown in a large size and increasing the build time with it. My observation in one of the teams few years ago was that we got used to build taking longer and which was considered more of a break from an hour or two of coding. What we did not realize was that subconsciously we were aware that the build is taking longer and hence we accumulated a large piece of code before checking instead of smaller chunks. This had an observable problem that there were build breaks just before we were heading home and developers sometimes take good amount of time merging code before checking in.
It was not until we reached a tipping point that the entire team realized that the build time has risen to a point where it hampers a smooth churn of development. To our surprise it was only few hours effort to get the build to under 4 minutes from 12-14 minutes. From there on some of us keep a conscious watch on the build times and have a 5 minute unwritten blanket rule to jump on fixing it before it grows too large. Usually the problem was a monolithic code base which keeps the build time too high. Some frameworks like GWT will compile JavaScript for all browsers which might not be required to be done for every build. Making use of the multiple cores now available so widely is also an option to consider. Ramdisk is also another option.
The lesser the build time, the more it encourages us to check in code often which reduces merge conflicts; eventually leading to a mature continuous integration. A mature continuous integration ensure reliable and effective delivery.
Every time I find it difficult to think of a good test to start, I am always tempted to try backdoors like getters, setters to help get started. The backdoors are not limited to getters and setters alone. Here is a list of my observations which has been used only for writing unit tests in Java easier.
Getters/Setters
Constructors
Equals implementation
Protected or package private access specifiers for variables and methods
ToString implementation
Special backdoor methods to alter the state of an object (The worst of all)
Any line of code which exists other than for another production code, it encourages a programmer in the future to exploit that backdoor for quick gains. As the tests are the specification to the production software, it is better to resist the tempation to use any of these. It also causes increase in code length and also an excuse for more people to follow the same path. The more time and effort I had spent trying to avoid backdoors, I have benefitted with more clarity in design. The benefits have prompted me to have routine static checks in the code base to keep them at check.
A question and a counter argument posed by a peer who belonged to another school of thought. If tests are considered to be first class consumers of production code, then is it right to have some backdoors help ease writing tests faster? Comments?
Many of the corporates have their own IT infrastructure and take care of long term maintenance of their IT software and hardware. When technical partners/vendors help them develop new applications, the entire development and testing environments are provided by the clients themselves. As access to these will be restricted, developers will need to be on the VPN always. Site to site VPN helps the entire development team be on the VPN. If every developer has to be on VPN then there is a pain of logging in individually, worry about traffic every time they browse or sometimes making their system not accessible in the local network.
Our development team had many machines with Mac and Ubuntu OS where we had trouble configuring the specific VPN software to work. We were also short of time to get the paperwork going and get a site to site VPN up and running. It was only with the help of few windows systems we were able to connect and run some tests and do development work. There was an urgent need for everyone to access client’s systems and resources, it was at this time Apache HTTP server and Rinetd came to the rescue.
This is what we did to solve our VPN bottleneck.
Get a machine such that the VPN software runs on that OS. In our case it was windows XP.
Give the machine an easy to remember name on the network like my-team-vpn.company-domain.com
Novi's 