I was recently hired by a large multi-national corporation to head up mobile development for their sales operation/support team. In a company of close to 10,000 people I am, at least in the America's, the only mobile developer. They are testing the waters and phase 1 (temp-to-hire) went well enough for them.

Now they are considering expanding to other developers for their other sales operations/support teams and I've been tasked with assisting/leading the writing of a standardization guide for iOS programming.

I am a big believer in giving people the freedom to work in the manner they most feel comfortable in but at the same time, I have been the creator of and on the receiving ends of big balls of mud applications. Having learned through experience I have several standards that I follow religiously such as commenting, at times almost every line - just short things but enough to let someone else know what is going on and using #pragma mark - DESCRIPTION to block off like minded methods, indentation, naming classes with a prefix to avoid name space conflicts, etc. etc.

So I guess what I am looking for is not to tell another programmer how they should iterate through an array but rather some basic standardization so anyone can jump into anyone else's project and find their way around with little learning curve. I'd love to see what other means people use to maintain control over a software development group.

  • 1
    Are you asking for "Coding Standards" or "Process Standards"?
    – Dunk
    Commented Feb 19, 2013 at 16:50
  • 1
    I'd be careful -- thinking that styling rules will help you avoid a big ball of mud is likely to lead to a beautifully formatted, commented, and indented big ball of mud. Commented Feb 19, 2013 at 17:30
  • @Dunk - I'd love to see how you approach both.
    – PruitIgoe
    Commented Feb 19, 2013 at 17:55
  • @Erik - I agree. The styling rules are themselves part of a larger mobile development process that will encompass the SDLC for our projects and the approach we will take.
    – PruitIgoe
    Commented Feb 19, 2013 at 17:56
  • @PruitIgoe Ah, gotcha. In that case, it seems that you have fodder for three different questions here, potentially: styling guidelines, architecture and process. That might be a lot of ground for people to cover in one answer. Commented Feb 19, 2013 at 18:00

2 Answers 2


A standardization guide is all well and good, but it needs to be accompanied by more - anyone can ignore a document. People often start with good intentions to follow a document, but they can often fall by the wayside.

Implementing things like peer code reviews, or a tool like FXCop for checking code design as part of your build process can help this type of thing.

  • That's a great point.
    – PruitIgoe
    Commented Feb 19, 2013 at 17:54

"Process Standards" is WAY beyond the scope of any possible answer here. The final outcome really depends on the industry and the customers you support. CMMI is necessary if you want to do government work. At the other extreme, look into Agile. Most likely, you'll fall somewhere in between the 2 approaches. However, keep in mind that no matter how meticulous you define your development process, your big ball of mud will only be avoided if you have quality developers. And your quality developers will avoid that big ball of mud even without a process. However, having a defined process is still valuable because at least having a plan and steps to follow will at least get people to attempt to do things properly and consistently; even if they aren't capable of doing it with any quality.

"Coding Standards" can be found on the internet for just about any language of choice. The only words of caution I'll add is that the more rules you have the less likely the standard will be followed. So pick the most important rules and leave it at that. Also, you really need a tool to help enforce the coding standards. And I don't mean one that will simply give warnings. Get one that will help to automatically correct the problems (e.g. ReSharper is great) then you can have more rules because the developer doesn't need to remember all of them and it is fairly easy to adhere to the rules with a couple of mouse clicks. If you use a tool that just spits out warnings, then people will stop using the tool because they won't think the effort to correct the warnings is worth the gain.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.