Applying the rules ...

Developing software has many things in common with aircraft development, depending of course, on how you look at it. In both cases, getting technical innovations to market as quickly as possible is key to success and while our users may not fall from the sky if our software fails, there are many software products that have enormous dollar and human cost when they don't work as they should. Even if a failure in our code will not endanger lives, we can permanently damage our customer base by releasing products that are painful to use. Turn off the users, and they may never be back.

Software is also like the aeronautical industry because projects depend on skill of the technical workforce. Once upon a time, you had to be a rare, geeky bird to want to work with data or hardware or code. Now the field is full of people who got into computers only because of the pay was high and the work seemed easy, although some of them may be regretting that choice these days. Finding a really good software person can be as elusive as finding a really outstanding avionics engineer, and if your project is important and you value your sanity, you need the good ones.

So I think Kelly Johnson's rules are applicable in our industry and I also think they highlight some shifting values that have been detrimental to business as a whole. In many ways, the 14 rules emphasis some very basic 'old school' values about how we work and how we manage the relationships of various contributors. There's an underlying tone to the 14 rules about respect, trust and ensuring the quality of your own work that interweaves throughout them as a whole.

I never met Mr. Johnson (not quite that old), but I worked with several men who had been part of the F-117 program and they had learned Kelly's rules by living them. Without exception every one of them had the same work ethic, the same drive to be the very best in whatever role they were assigned and the same desire to be part of something amazing. They could be cowboys at times and sometimes, the need to get the job done well came before the procedure book, but Kelly's rules they followed.

I recognize that it's a bit presumptuous of me, but I've taken the liberty of rewriting the 14 rules specifically for managing software development. I don't claim to be an expert on this topic, so if you see a rule you disagree with, one that could be better written or you think something should be added, please speak up. In recognition to Mr. Johnson's appreciation for concise documentation, if we decide to add rules, perhaps we should combine some of the others. 42 rules might have a nice ring to it, but that may be a few too many.

14 Rules for Managing Software Development

1. There must be a strong project/program manager with a clear vision for the future of the product and the ability to communicate that vision.

2. Project management teams must be strong enough to ensure momentum toward the goal and the tasks needed to achieve it, and small enough to work effectively.

3. Teams must be as small as possible to remain efficient. This means the people must be good enough to do the work of many and do it well. Developers are not interchangeable parts: choose carefully and recognize their contributions.

4. Change control tools should support the developers in getting their work incorporated quickly and accurately. Tools should not be create a roadblock to a clean release.

5. Determine the critical success factors to a project and the most dangerous risks. Reporting on these factors must be concise but thorough.

6. Review and report project costs at a regular interval appropriate to a project's length and scope. Maintain visibility of potential impacts to final costs and keep the appropriate people informed.

7. Your vendors are as critical to the success of your product as your team. Find the right vendors for the work and never forget that your success depends on the quality of the work they deliver. You are in their debt, not the other way around.

8. If you've hired or contracted good people, you can trust them to do initial testing and avoid duplication of effort later. Test modularly at the integration points and ensure code packages are moved in concert. If you've selected the lowest cost option, re-inspection and waste will cost far more in the long run.

9. Designers and developers must be provided adequate tools and access to test their work. They must remain intimately involved with the technology of their expertise or they will lose the knowledge and skill needed for the next design.

10. Specifications applying to the foundation of the product must be determined and documented in advance, and the foundation includes the hardware, the operating system and the core database structure. These components are difficult and expensive to alter late in the project. Scalability should be the first consideration, not an afterthought.

11. Projects must be funded adequately to prevent money issues from becoming a distraction. Shortchanging payments results in vendors and contractors needing to shortchange their work.

12. There must be mutual trust between the customer and the contractor, and/or a contractor and the subcontractor. Communication must occur frequently to avoid misunderstanding, and correspondence/documentation must be concise and direct.

13. Access to product development information and personnel should be limited appropriately to protect intellectual property and to minimize interruptions of the team's work.

14. When teams are small and talented, pay must be based on performance and contribution to the product. Small teams result in a flat organization and good technologists must be self-motivated. Reward them appropriately.

I think Rule 15 needs to remain an unwritten rule, so adapt it to your current situation (employers, bosses, customers, etc) as you see fit.

And as you think about the rules, remember to thank the people who make the contributions you are able to depend on. Whatever your role may be in the big picture, there are people that make it possible for you to do your job well.