Software Development Standards
It all comes down to this.
When I put this depiction in to word, I would say it as “Industry Standards > Organization > Team > Personal > No Standards“.
It is that simple. Everyone has standards. However, some standards are more important than others. When developing your own standards you should consider those standards that are greater than you first. So your standards should extend those standards that are defined above your position.
As an example, consider a Java developer working for a major US Bank.
Industry Standards
Most developers have two industry-level standards to consider. First, the language that you are developing in. Our example developer is a java developer. Sun publishes a Code Conventions for the Java Programming Language. This document provides a broad range of guidelines for various facets of the language. Next, consider the financial sector’s software development guidelines. You may or may not be able to find such guidelines, and when you do they will probably not be specific to your language. I’d imagine there are rules for how many decimal places into dollar amounts you should keep, and how to store currency types are all documented somewhere.
Organization Standards
Now that you’ve adopted the industry’s standards, look to your organization. You might be a member of a huge multinational corporation, or a small 2 developer shop. Whenever the industry does not cover a specfic aspect of your software, your organization has the opportunity to define standards. These standards may be how to name your SVN repositories, or how many characters long your variables must be. These are things not covered by, for example, the Sun Code Conventions for the Java Programming Language.
Team Standards
Your organizaiton may not care about some aspects of their software, but your project manager or project team may still have rules that they follow. These are standards that you and the other developers on your software project or team follow.
Personal Standards
Finally, you have a situation where there is no defined standard anywhere. So you get to decide how you will perform some task or format some code. Whatever you decide to do, think it though, and do the same thing the same way next time. Personal standards are important weather you are working in the office or working at home on your own project. You are the same developer on both projects. Your code should reflect that fact.
No Standards
Why would you code in one style in the office only to drive home and code differently on your home project. This is chaotic. This can prevent you from effectivly transfering experience from your office projects to your home projects.
Documentation
De Facto standards are those that tend to happen not because they are law, but more out of practice. There are no such things as de facto standards. Standards should be and must be documented and developers must know where to find this documentaiton in order for the standards to be effective. This documentation should be easy to find, easy to access, and even easy to update.
It is sometimes hard to define a standard that covers all situations. When developing your doucmentaiton, you might consider defining the typicial situations that those standards fit into. These leaves the hands of your developers untied so that they can focus on producing high quality software and not be bogged down by unneccesary blanket rules.
Wikis are great tools for maintaining software development standards for a small organizaiton or development team. They allow team members to update the documentation as new standards are developed and as new situations are encourntered. Other developers can usually subscribe to the wiki to be notified of changes so that everyone is always up to date.
Why are standards important?
Following standards are not about making software development harder or more tedious. They are about making development easier and cheaper. InfoQ recently posted an article called Better Best Practices which listed a few great reasons for developing best practices, but it turns out the same reasons for developing best practices hold true for following standards too. Their list is titled “The motivation for Best Practices” but I could easily title this list “The motivation for following Standards”:
- They ensure consistency. We are introducing [insert initiative] and we want to ensure that everyone goes about it the same way. We don’t want to abandon people without offering them any direction and the alternative would be chaos.
- They support learning. We are trying to get everyone up to speed on this new approach with the minimum of fuss, and having a standard set of well-structured material means people can see exactly what they have to do, and ideally how well they are adapting.
- They help limit (potential) impact or damage. (Now we are starting to see their true colours.) In any organisation there’s a bell curve of people’s abilities, and we know that a small but significant number of people will be at the wrong end of it. Implementing this program badly could leave us exposed to significant financial or legal business risks, so we’re going to need very clearly defined practices to protect ourselves. They are called Best Practices because they are tried and tested so I can be reasonably sure they are going to work.
- They help to build a more mobile and flexible workforce. In these fast-moving times, projects can materialise or be cancelled almost overnight. People move between project teams, projects move between offices, countries or timezones. With all our people trained up to use the same Best Practices we – and they – have many more options in terms of career mobility. We call it “commoditising resources”.
- They allow us to enforce control. In a large, hierarchical organisation, this is the real crux of the matter. A division manager or vice president may well be responsible for thousands of people. The only way to provide accountability on that scale is to have a system of clearly-defined and strongly-enforced Best Practices.
What do you think? Are standards a waste of time? Or do they create time? What good or bad experiences have you had with some enforcer pushing standards down your throat. Were those enforcers in the right or the wrong?
Nick, 
Tom and one other person are discussing. 
Jamo are discussing. 
Eric 11:51 am on July 29, 2008 Permalink
would you have the same revenue benefits if you did not use a viral oss license (e.g. lgpl or apache)?
Mike 12:17 pm on July 29, 2008 Permalink
@Eric – No. Duel licensing will not effectively make you any money if you do not use a license that requires the users to contribute their derivative of your project back to the open source community. The only reason that a business would pay for your license is to prevent themselves from having to share their proprietary secrets.
So with this type of duel license, other open source projects can use your product without purchasing a license, while businesses that are likely to generate their own revenue with your product will likely purchase the license and generate revenue for you.
Tom 6:54 am on July 30, 2008 Permalink
“So, in order to use the free half of this duel license, the using organization would have to contribute back anything they develop using your product. This means their proprietary trade secrets are potentially being made available to the public. Many organizations would rather pay a small fee to protect their competitive advantage.”
Hmmm… sounds a bit misleading!! Taking LGPL as an example… organisations using software distributed under this license would only have to contribute back changes/enhancements they make to that LGPL software. They don’t have to LGPL their own proprietary software that has a dependency on the LGPL software. So, your statement that “… their proprietary trade secrets are potentially being made available to the public” is not at all accurate!!
Mike 8:58 am on July 30, 2008 Permalink
@Tom – The more restrictive the license that you use, the more effective the duel licensing will work. I’d recommend the most copyleft you can get: GNU General Public License.
In fact, I found a specific example. GlassFish is duel licensed. From wikipepdia:
Nick 11:03 am on July 30, 2008 Permalink
So does this concept of duel licensing involve 50 paces with vintage revolvers as sidearms? I much prefer discussions about dual licensing personally….
(I’m sorry, I just couldn’t help myself!
)