ablog_The Army (of Developers) You Have

If Donald Rumsfeld is to be believed, and you go to war with the army you have, then there are specific challenges to technical projects that must be addressed proactively. Before you even begin a project there are questions to consider concerning your resources, training, and expertise. In any given project you will usually begin with a problem statement. From this problem statement you begin to deduce the course of your proposed solution. This evolution should include an evaluation of resources and skills, but far too often it does not.

Consider the scenario when a problem seems to indicate a specific solution. For instance, the problem lends itself well to a specific technology or platform. All too often, managers will spot this inclination and follow it, allowing further consideration of the solution to be guided by this initial evaluation of platform. This is very likely the case in any solution devoted to supporting a legacy system. Often the legacy system determines the course of the proposed solution (since rarely is an alternative system considered).

Many times these sorts of solution paths are defended in terms of time or cost. Switching to a new system or utilizing a different, less well suited technology will require more time and energy. These are often valid points, but unfortunately many people fail to consider the full evolution of a solution, especially an evolution beyond the expected life span of the project.

All too often project run over budget, either in terms of time or money. Many times solutions that seemed like quick fixes become long term support projects. These situations are rarely considered when initial discovery and planning is being carried out and projects suffer because of it.

When designing any technology solution it is vital to consider the resources available. Realizing the full impact of this statement is often difficult. If a project seems to lean towards implementation of a certain solution, be it technology or platform, and you don’t have availability to training, skill, or expertise in that technology or platform, the project should not necessarily take that direction. Many times project leaders decide that a certain technology will best meet the need of the project, and then they hand this dictum down to the “worker bees” to implement. Often times there is an assumption that the project workers can acquire the skills necessary to use the technology. This is a fatal mistake. As any experienced developer knows, your first project with a technology is always your worst effort. Only with time and experience do developers become proficient with technologies, no matter how experienced or skilled they might be with other technologies. Implementation is usually hacked and poorly developed because the implementers are unaware of common pitfalls in the technology until they encounter them.

For this reason, an evaluation of available resources should play a critical role in project planning. It is better to implement a skillful solution in a technology that doesn’t best address the project than to create a poor implementation in a technology better suited to the task. This means that sometimes you won’t be using the best tool for the job, but you will always be using the most skilled tool wielders on every project. Teams must play to their strengths to ensure a quality product.

This situation is starkly clear to anyone that has ever had to maintain a system developed by a novice with the technology. It is much easier to maintain a well written and developed system that rests on technology which may not be best suited for the job than it is to try and fix or figure out a system made with the right technology, but by an inexperienced developer. For instance, writing a desktop application, PHP-TK probably isn’t your first choice of language. However, if your team includes skilled PHP programmers, but no Java or C# experience, you would be better off writing a clean, well developed PHP-TK application than asking your team to learn Java or C# and attempt the same job. While the latter languages are better suited for the task, you can be sure that the code quality will be much lower, and in the long run the project will suffer.

Similarly, when examining legacy projects, it is better to evaluate scrapping the product altogether and rebuilding it with the assets you have than to assign people skilled in alternative technologies to maintain the legacy system. If the system starts out well written then the maintainers will have an easier time in the beginning, but over the evolution of the maintenance the inexperience of the maintainers will begin to weaken the overall product. Over time, these weaknesses will grow and may reach the point where even a skilled person would be frustrated by the evolutionary product.

Understanding this situation necessitates that to have a good team for a diverse breadth of projects you must invest in training. This includes allowing developers to “waste” time learning and evaluating new and alternative technologies. Utilizing this policy ensures that developers become experienced with technologies on outside projects, freeing internal work product from the mistakes of first time endeavors.

Of course, most people have a strong work ethic and aren’t likely to investigate outside technologies or solutions without encouragement. It is important to regularly remind your staff to “play” with new technologies, platforms, and solutions. Providing a structure to this exploration only helps, and as your staff gains knowledge and skill in alternative technologies they become better able to handle diverse challenges.

Going to war with the army you have means insuring that your army is always in peak form. Allowing your developers to work on side projects, even when “real” projects and deadlines loom may seem difficult to justify, but the mythical “down time” between projects rarely exists. Allowing one project to slow so your staff can train and grow means the next project will be faster and better, resulting in a net even gain. While your current project may seem to be slowing, the investment made in future projects balances any temporary shortcomings.