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.

1. Get a machine such that the VPN software runs on that OS. In our case it was windows XP.
2. Give the machine an easy to remember name on the network like my-team-vpn.company-domain.com
3. Install Apache HTTP server and set up ProxyPass and ReverseProxyPass such that all the HTTP based test environments are given a local url. Like http://my-team-vpn/QA-env/index.html should serve from http://client-machine-QA-env/index.html
4. For other TCP connections like DB and LDAP, setup Rinetd and configure redirects like 10.1.1.1 369 to IP and port on the client machine.
5. Keep the machine always on the VPN.
6. Publish the URLs and ports to be used by the development team without using VPN.

With the above steps we were able to complete our development without going through the paper work of setting up site to site VPN.

Image: jscreationzs / FreeDigitalPhotos.net

If numbers come into play then quantification is implicit. Most of the projects I begin, I start estimating use cases in “High, Medium, Low” or “Small, Medium, Large”. Before the development starts we need to know how long something is going to take, hence we estimate. When we arrive at an estimate and put a schedule in place, subconsciously every one gets tuned to the numbers.

The numbers help in planning and helps the first release goes through; then the economical activities begin. Questions start arising like ‘Why two use cases estimated to be of the same size when one of them have fewer tasks?’ or ‘Why did two use cases with similar sizes take different times to complete?’. The completion of the use cases is what shows up as progress and slowly an illusion is created that the reduction in estimate is equal to the money saved. This leads to addition of scope similar to salami slicing.

The effect of salami slicing becomes visible over the course of time and developers begin to compensate by increasing the estimate. This vicious cycle leads to inflation and deflation of estimates, which in turn affects the project management’s ability to predict and plan. Quantitative/Objective measurement gives an illusion of control but will eventually affect the team’s ability to deliver value because there are lots of parameters which affects how something can be done; attaching a number to it will create those numbers to behave like currency. When we have something like a currency then we have economics.

Should estimation be very accurate?; No, it is like saying that with all the historic data and current conditions, we will be able to predict the outcome of cricket matches accurate to the number of runs scored. We should have estimates only as a guideline for planning and acknowledge that pin point accuracy will never be possible. Productivity is a result of so many factors and trying to assess that with a single number will result in expending time and energy away from productive tasks.

Image: jscreationzs / FreeDigitalPhotos.net

I often come across the illusion that a productive day for a developer is to churn out as much code as possible. This illusion creates an  expectation to keep coding for the whole day and cut short time to design, reflect or retrospect.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight

The answer to the question of measuring productivity is very difficult especially in the application developer’s world. Every one wants something such that it either enables them to earn more money than what they spent on acquiring it or it gives a sense of satisfaction on using the product (Essentials and Luxuries). Same is the case with every business who wants a software and present the consultants with what software they want most of the times instead saying what is the problem they are trying to solve.

It is expected of every programmer to make sure what we do is what the customer really needs instead of being a human translator to get specifications into working software. After a careful analysis we may even have to ditch the requirements or spend more time in sharpening the tools get usable working software soon, most of the times do both. I came across this post by John D Cook, who illustrates that sometimes a programmer can be 10 times more productive than his/her peer but it will not be obvious at all.

Numbers are useful mostly to indicate an absence of something. If we concentrate on creativity and problem solving instead of  getting some numbers on board we would end up being very productive.