Vision goal and characteristics of an excellent software development department

Question

I like quality software development, and this all might sound airy fairy, but I think it's important to strive towards and also project out to upper management what we are all about.

I am looking for suggestions for a vision goals to strive for in a software development department. What should you be doing and what characteristics should you have as a team?

Answer 1

Years ago, fresh out of school, a mentor listened to my desires to improve the local codebase, and offered an important insight. If you're trying to sell change to management, you need to communicate how it advances business goals.

Business goals might include, for example, greater productivity, reduced cost, reduced risk, reduced downtime, greater reliability, increased automation.

Let's say you've entered an environment not yet investing significantly in unit tests. (It still happens.) There is an up-front investment to write unit tests and unit-testable code. You need to communicate that the costs of this investment are exceeded by increased reliability, reduced schedule uncertainty, and improved productivity over the long term.

In terms of vision goals, here are a few resources.

• "The Joel Test" by Joel Spolsky
• XP practices - Even if you're not using XP, at least some of its practices may still be desirable, such as iterative development, continuous integration, unit testing, colocation, and a sustainable pace.
• Industry-standard coding standards, like Sutter and Alexandrescu's "C++ coding standards" and Joshua Bloch's "Effective Java".

Answer 2

I suggest you adopt an engineering viewpoint. Most engineering areas (civil, industrial, aerospace, architecture) are based on solid principles that work. This is especially important if you are concerned about (as Andy Thomas-Cramer suggests) cost, risk, reliability and other issues that lie in the technical-business interface.

Engineering means knowing the stuff that you are dealing with, and I mean knowing it deeply. For example: a civil engineer does not build a bridge in some manner and then refactors it until it passes some pre-designed tests; rather, the bridge is designed with a priori deep knowledge about the properties of the structure and behaviour of the matter that makes it up, and making informed and meditated choices about the best possible design for the existing requirements. Tests are useful to expose defects, not as a replacement for deep knowledge.

Engineering also means repeatability, i.e. having methods that guarantee that you will be able to achieve excellent results all the time, every time.

Engineering also means a high degree of professionalisation of the discipline. Software development is very young as compared to other engineering areas, and this may be beyond our control in many aspects. Still, we can strive to be highly skilled and competent in a wide range of central and peripheral topics that are important to software engineering.

Hope this helps.