Getting a bunch of engineers on the same page about anything has been likened to 'herding cats'. Getting them to agree on a development platform and language standards may as well be likened to 'herding tigers'. Read the fictional story of Global Amalgamated Worldwide Designs (GAWD) and learn why you should probably spend the energy.

	Oh, GAWD! Once upon a time, Global Amalgamated Worldwide Designs (GAWD) decided to build a widget. After finishing the requirements for the widget, GAWD put all its programmers in a room, and said ‘go forth and build thy widget’. So the programmers reviewed the requirements, and divided the tasks amongst themselves. And then each programmer sat down at his terminal, and began to write code. And the code flowed forth from the keyboards like wine. Good, clean code. Beautiful code. After a fornight, each programmer finished his task. And he submitted his code to the group, and the group put all the pieces together, and went to test their widget. And the widget didn’t even compile! “There must be a simple solution” cried one! “Let us examine our code” cried another. And there, plain as day, was the problem. But there was no simple solution. Each programmer had written his code differently. Some had used obsolete functions from outdated versions of the language. “But that’s the way I’ve always done it”, one bellowed. Several had used conflicting libraries. Each shouted “but my library is the best one!” After much debate, the decided on one version of the language and one set of libraries. And so they went to fix each other’s code. But as each programmer sat with his assigned companion, they realized another problem. For two weeks, they hadn’t talked about how they should write code, so none used the same variable name or function name conventions. Filenames and comment styles were all different, and only the programmer who wrote the original code could possibly know what it did. And as they realized the magnitude of the problem, they humbly went to GAWD and told it that they would need another fortnight to finish the widget.

If you’re just starting a company that will build software of some sort (web based, desktop or otherwise) you don’t want this to happen to you. Choosing a language, a development platform and a set of coding standards up front can be a daunting task. If you have technical staff already, this is likely to ignite all sorts of religious wars. If you don’t, and aren’t technical yourself, you probably don’t have a clue what to do, but you likely know enough to know that you shouldn’t make the wrong choice.

First Things First: Pick a Langage

First things first: pick a language. The most tempting thing to do, especially if you are a programmer yourself, is to just pick whatever you have the most experience in. Maybe its PHP, maybe its Java, maybe C#. This isn’t always the best idea. In fact, I would encourage you not to simply use whatever language you or your programmers are currently most comfortable with, unless you are building a throw-away prototype. While this may be the easy choice, it can prove painful in the long run. For example, many people use PHP as a fast web development application. You can do a lot quickly, but being non-object-oriented, it can come back to hurt you later. (Yes, PHP fans, I know that v5 has introduced a lot of object-oriented features, but the fact remains that it still doesn’t support some object oriented basics, like local namespaces.)

Fortunately, figuring out what language – or languages – you should develop with isn’t that hard. Here are some guidelines:

• Pick a popular, modern language. It shouldn’t be too old-school (e.g. COBOL) but shouldn’t be too new either. You want something that a lot of programmers know how to use, and that has broad industry support so that your developers can go to conferences, participate in online discussions, etc.
• Figure out what other companies in your industry use, and consider that. As a second step, figure out what possible partners use (this can be harder to do, from a practical standpoint) and consider that. Although it certainly isn’t necessary anymore to use the same language as partners in order to exchange data with them, it certainly doesn’t hurt.

Next Up: Figure Out What Version to Use

Second, establish what frameworks and libraries your application will depend on, and which versions you will use. For example, if you’re developing in PHP, you’re probably going to want to use a template system of some sort to separate your application logic from your display code. But there are plenty of choices… you can use Smarty, any of the PEAR varieties, or YATS, or PHPTAL. So what’s it gonna be?

Stick to whatever you decide, unless it starts causing you really major headaches. In a past life, I was writing code for a message board/forum application, and it dealt a lot with time and dates. As I was testing my code, I kept seeing posts showing up at the wrong time. After much hair-pulling, I found out there was a bug in that version of the Perl interpreter that caused the system to incorrectly calculate GMT time from the system clock. It wasn't there in the last version of Perl, and had been fixed in the next point release. Upgrading to the new version of Perl might have been an obvious choice, but instead I worked around the bug with a helper function. Why? Because an upgrade would have potenitally caused innumberable hassles for both myself and other developers, and the helper only took 20 min to write and test.

Once you get your language platform choices made, you’ll want to setup your build environment, but that’s the subject of another article.

Finally: Get Some Coding Standards In Place

	Just tell everybody else 'do it like this'

Last but not least, its probably a good idea to establish some coding standards amongst your programmers. This can be as simple as having a quick discussion amongst your development group, or it can be as formal as documenting everything in a big binder. As a practical matter, however, I usually like to have somebody make a sample file that is perfect, and tell everybody else "do it like this".

Here are some questions you need to answer:

• What shall we do about comments? What’s the minimum standard? I don’t think I’ve ever seen code that has enough comments, short of code in technical demos written by vendors. At a minimum, I’d recommend that you have filename, author name, last date modified, and a description of what the code in the file does at the top (some of this will be contributed by a source control system such as cvs or subversion, if you’re using such a thing). Realistically, you probably want to add to that list a few things, such as a list of changes, and perhaps a list of variables or list of functions in the file. Throughout the file, each function should be well commented both a the top and within the functions themselves.
• VariableNames. Or perhaps I should say variable_names. Or maybe Var_Names. Figure out a standard naming convention for both variable and function names, and make everyone stick to it.
• Whitespace and Linebreaks. Generally I just say to use lots, and leave it at that. If you want to be anal, you can try to decide where programmers should put curly braces and whatnot, but that is probably overkill.

If you can get your programmers to decide to take care of these things upfront, you’ll avoid the awful experience that Global Amalgatmed Worldwide Designs had. Then the only thing you’ll have to worry about is what to do with all that extra time. I’ve got plenty of ideas for you.