Be Different…

Jan 2006

Vibhu Srinivasan

Programming has evolved over the years and has gone from what was once a specialized skill to that of a commodity market. In the majority of the companies where the core of the business is not IT, like a manufacturing or healthcare, the budgets allocated to IT is a fraction of the overall budget.

At the same time, the salaries and pay rates in the US have decreased or have leveled out.

However the level of complexity of programming has not changed in any way. Although there are certainly much more mature languages like Java and .NET, and tools like IDEA and Visual studio, every company is constantly faced with phasing out old technologies in favor of newer technologies as the market demands more features that cannot be supported with older technologies.

Example - Try writing a web service in Pascal or Access. (Although there are companies that actually may have something to do something like this).

Due to lack of funding IT managers are forced to tighten the bolt on programmers and yet demand quicker releases and do more for less.

Before we go further lets define a Cheapmatic programmer.

A cheapmatic programmer is one who is simply measured by their hourly cost or overall cost and not on any other factor.

(A Java programmer - 50 dollars an hour, A C# programmer 70 dollars an hours , A pragmatic programmer – Priceless )

This article looks at some key factors that motivates “Developers”

PRAGMATIC PEERS

Work is a place where we spend the most active part of the day. This is the time where we can be most productive. So it only behooves managers not to create a place where programmers can work with other pragmatic peers who are skilled and knowledgeable and fun to work with.

If the place is filled with less motivated programmers, complaining testers and project managers who are only interested in deadlines the productivity is bound to go low.

In the end companies end up spending more on projects as they take longer to do due to the effectiveness of the teams

DEVELOPER VALUE ADD

In many places, developers are not told how their effort is paying off in the big picture.

Very often you are simply moving from one project to another without really understanding how this all fits and benefits the business. If a developer does not realize the value that is being added because of their work, they may do things that may not necessarily fit the big picture.

ABILITY TO INNOVATE

Many developers are simply taking the easier route of GOOGLE based programming. Although GOOGLE provides a large wealth of information, it is questionable how we can simply trust the code or idea that is presented by Google.

Remember that most of the good programs in companies are behind firewalls and GOOGLE can’t get to them.

Many of us (developers) do this GOOGLE based programming partly due to the lack of time to innovate.

IT managers should allow some time in a developers week for them to innovate (Think out of the box). Not every idea needs to be used in the project, but it is worth the bet to get the creative mind going and see its fruitful results.

Remember a big part of Google’s success is their policy to allow developers one day on a week to spend time at work researching and doing things they like and want to pursue.

A BETTER WAY TO MEASURE PRODUCTIVITY

Today developer productivity is not measured in most organizations. The most common non practical metric seems to be “Did the project make it in reasonable time and within budget to production”.

The way we estimate projects does not even factor into it the developer productivity. We estimate it often assuming a project managers perspective or ask the developer to estimate it. It someone does not clearly know how productive they are, how can they estimate a given work?

I am not sure what this metric is, but the one I like a lot is the concept of velocity points. It’s like a car, moving at a velocity of 4 level four tasks in a day, the 16 level four tasks can be done in four days. So if we start categorizing the tasks we do in programming into some basic a categories then it may help better in estimating.

So we can says things like “Tom has a velocity of 10 points in a day, while Mike has only 4 points to do level four task that take X days.

The point is there needs to be a better measurement system.

THE NEED TO FOCUS

Many firms have so many policies and procedures to do a certain task that most of the day are spent fulfilling these tasks instead of focusing on the code. Coding is a thought intensive process and by asking a developer to do other tasks also at the same time they are writing code, is taking them away from their thinking time.

Status meetings at 10 AM are a classic example. Mornings are the best times in a person’s day. A developer can use that time being most productive by focusing on the code and not having to go to meetings.

Although open offices are XP’s way of being productive very often you need to phase out from the world to write good code.

So IT groups have to strive to seek that fine balance between those tempting meetings and IM chats to focusing on the code.

Conclusion

Although this is not an all inclusive list, this is surely a good start where Tech Leads and IT managers should focus and strive to improve upon.

Writing good code is not a commodity market. A software program lives longer that often thought. When its time to look at the cost of a new development project, it is important to look at the overall cost including the cost of maintaining the project for the life of the software product.

Adding good developers in a team and providing them the right set of intellectual tools will only enhance the product quality and go a long way in reducing the Total cost of Software (TCS).

The person who can make the difference is the Pragmatic and not the Cheapmatic Programmer.