Managing Software Development

Herding Cats

Managing software development can be a difficult task. There are a dizzying array of methodologies and theories about what is the optimal path. Hiring and managing programmers, architects, business analysts, and architects requires great effort and experience. Programmers alone are a unique breed. Anyone who has managed large software development will usually say there are a few major “rules of thumb” to go by. Here are some of my rules of thumb…

Great Software Is Not Written, It Is Re-written

This is proven over and over again, yet many methodologies (especially the old waterfall development methodology) don’t take this into account. Simply put, you will NEVER GET IT RIGHT THE FIRST TIME. So plan to rewrite the system. Design the system and your processes around rapid change and you will be far better off.

Design The System, Don't Just Start Building

It is often the path taken by inexperienced software managers to spend no time on system design or architecture. This is a terrible error. Often this occurs when a programmer has been “promoted” to manager. Another mistake. Not always, but often. Most development managers have never spent time as a system architect, so they simply don’t understand how to do this or why it is important. I count my time as an Enterprise Architect as some of the most valuable of my technology career.

Requirements Are The Hardest Part

The tools available for software development today are very, very good. Software can can be built VERY quickly, if you know what to build. Unfortunately, non-technical personnel can rarely spell out their needs for a given system. A current popular theme is to let a pre-built software package determine the business processes. This is lazy and unnecessary. After all, what makes a company unique is the way is does business. Putting an electronic straightjacket on your firm is simply not a good idea. It is up to the development manager to put an effective requirements elicitation process in place. Often a technical manager will need to go the extra mile to make the business personnel comfortable talking about what they need from a system. DO NOT MAKE THEM FEEL STUPID OR IGNORANT. This is a common mistake technical personnel make. Business people feel out of their element talking about software, because they don’t know what they CAN ask for, as they don’t have a full understanding of the possibilities.

Identify A Lead Programmer For The Build

Even the most knowledgeable technical manager will encounter technical issues he/she cannot readily solve. A strong senior developer can be invaluable in making those judgment calls. It is not just the smartest or most senior guy/gal on the team. Make sure your lead has the best judgment of the developers. I’ve encountered plenty of genius programmers with terrible judgment.

Be Willing To Change

Often on a project, an early technology choice will begin to cause difficulty. I’ve had application servers, development tools, operating systems, etc., become tremendous hindrances in the midst of development. These choices seem like absolutes, but THEY ARE NOT.
Some of my greatest successes have been when I threw out a major piece of the system and just admitted it was a bad choice. This can be daunting, as you are admitting failure. However, what is important is THE SUCCESS OF THE PROJECT, not a little egg on the face partway through.