Posted on by JesterXL

Implementing Coding Standards in Your Workplace?

Every time someone blogs about the way they code on a blog, the comments always have one person who writes about how their company/department/group has the described technique as a coding standard in their company. From using a new line for squiggly brackets, to no code on the timeline in Flash files, all the way to using a specific coding framework (Rails, Mach-2, Cairngorm, etc.).

What I want to know is, how does one “implement” said standards? How does one enforce them?

Reason I ask is that in my new job, I’m taking the ball with formalizing a variety of projects and code bases to fit a road map. I work with a team, and that team is on a variety of projects, each of which has their code base. My concern for the client side Flash and Flex portions is that there is currently no enforced standards. We can all code on our own way because currently we have very little involvement with each other’s endeavors. The expectations are that you code well, hit deadlines, and keep management informed.

That’s all well and good for the short-term, but after seeing the business ramifications of a few code bases not coded with the future in mind, I have grave concerns. Business ramifications being an insane overhead cost for feature requests, no risk-free way to test the already written software, and more risk associated with particular individuals being the only ones who know how certain systems work. I’m worried that I’m not doing everything in my power to ensure that if I get hit by a bus, those taking over the code bases after me are well equipped, and can be successful in doing so. Conversely, I dread maintaining some of the other code bases that aren’t using the standards I’m using.

I’ve got what I feel are obvious things:

  • using best coding practices (those that aren’t too subjective)
  • following OOP encapsulation, and documenting where I break it, and why
  • using Subversion source control, checking in only what you need to successfully compile and run the app
  • What I check into Subversion actually compiles
  • communicating my intent to other developers and getting their feedback
  • Using widely known frameworks (1 for Flash, 1 for Flex)

What I haven’t done, but feel might be good to do:

  • Provide a document beyond code-commenting per project on how to setup and compile
  • Document my framework modifications that go beyond implementation details
  • Have more debates on the pro’s & con’s of unit testing with a particular devote developer from another team
  • Voice my concerns to management to ensure I’m not wasting my time.

That last one may seem weird, but it’s not. For example, a lot of service work is created once, and never maintained. In consulting, some stuff is coded from scratch for each client to ensure there are no legal licensing worries after a project is done. Sometimes, it’s just cheaper to re-write, whether in house or out sourced to another company/contractor. For product work, some customers are charged out the yang for things beyond the norm.

I don’t think I’m wasting my time, though. In my short career, I’ve seen first hand how bad things can be when the original developers do not plan for the future, nor care about it. I want to create a better future, whether I’m in it or not, and not just for the engineers after me, but also because I want research & development funding. If I reduce overhead costs, while ensuring customer satisfaction is at or above where it was before I got involved, I can spend more time coding new products, improving existing ones based on what customers want, and/or creating what the sales’ team sells.

To do that, I have to ensure the code is stable, can be configured easily, and is insulated against change. This doesn’t just apply to me, though, it applies to the entire team I work with, as well as new employees, and this is where my vision breaks down. The only way I can think to do this is to first become in charge of my area; second, mandate standards the team agrees on; and third, make people fix the things that don’t follow standards.

Is that how you do this? Do I really need management’s buy in or is this something developers can mutually agree on? One of mentor’s claims I shouldn’t even waste an ounce of my time on my team members, and instead should go straight to management to make some coding standards company law… I’m thinking I agree with him.

Do you have coding standards at your company/workplace/department? Who created them, how did you implement them, and most importantly, how do you enforce them?

10 Replies to “Implementing Coding Standards in Your Workplace?”

  1. I would stress less the “becoming in charge” and “mandating” and stress more the “agree on”. If you are forcing anything down anyone’s throat, whether it’s an issue of formatting, or what framework to use, it’s not going to stick, no matter who from management signs off on it. And if you can’t come to agreement on stuff like that, you’re already in trouble.

  2. I echo Keith’s sentiments. From my experience it isn’t that hard to implements standards once developers “buy” into it. I am part of a growing tech team and we have pulled bits and pieces from each other techniques that is used as the basis of our “standard”. Its not written in stone but used by all of us because we see the merits in using them. I am the usually the youngest developer on a team (and I have worked with three different teams in my short career) and usually expect to have a hard time getting my ideas across but that has never been the case. Once you can deliver the idea (and get developer’s interest) and then execute and show what you said was true (and not some wishful “theory”) developer’s are quick to embrace it because ultimately we love to code but we like to be home on time as well.

  3. Work towards creating a better future, but not at the expense of your teammates. While getting standards set is important, remember you also have to work with these people day in and day out. I’m not sure if you’re *just* in the door or if you’ve been there a little while, but either way, stepping over your teammates collective heads and demanding standards to the management isn’t exactly the best way to build good working relationships. That being said, decisions by committee don’t tend to work out too well either. I would do a good mix. First, plant the seed with management (so that a teammate doesn’t back-door you). Then set about selling your team on the idea. Once they are sold, sell it to management. Once management is sold, create it. Pass it by team members. Even if you can’t implement everything they want, show that you’re listening to them, and be honest with them if you don’t plan to include their ideas. That way you can make your work environment better AND not lose any friends. More importantly, like Keith said, if the teammates don’t feel like they got to put any skin in the game they aren’t likely to adopt the new standard. Also, don’t be afraid to tell people no either (and in a scenario like this you are likely to have to do so quite a bit to come to one spec), so long as you have a good reason people are likely to understand.

  4. Implementing a standard within an organisation is hard – whether it’s coding or anything else – been there, done that. Ideally, everyone (all stakeholders) should agree on the standard and actually follow it, however it’s very difficult. Programmers can get into endless debates for trivial things as to where to place the brackets. I had a co-worker that was opposing (vehemently) to the idea of using any versioning system (no, really, he did).

    My advice – Have the management back you up, you should have some serious authority on this. Talk to the team, get the ideas, see where they converge. Then organize the ideas in a coherent document, cover all areas, be very specific but not redundant. Present the doc back to the team for feedback. You won’t get everyone to agree 100% but do listen to criticism. Once the standard is finalized, get everybody to sign it, just like they sign any company paperwork.

    Also keep in mind, standards are not immutable. From time to time (1 month, 6 months, 1 year), review it. See what worked and what not and improve it based on experience.

    Having a coding standard (no matter how weird) within a company is very good idea. We do where I work, and it’s nice because I can easily pick up the code written by someone else and feel very quickly at ease.

    Good luck!

  5. Formal code reviews and repository sign-off works well. We all write sloppy code at times – a second set of eyes helps keep it contained.

    Part 1 – Have formal code inspections.

    Part 2 – Have a repository manager require proof of 1 before allowing a code commit to take place.

  6. Controversial Warden, you’re starting to think like a suit rather than a developer ;)

    Seriously though, I think the outcome you’re after is the right one, but as the other commenters indicate going straight for the jugular via management wont fly with the rest of the team. Get the team together, suggest you think “we” should hit up management to approve a company standard that “we” define. I assume you’ll get their backing (as keith said, if not I think it’s time to review the team rather than the code) then take the notion to management that you want approved time for standards setting (up front and regularly reviewed) with the team for the reasons you mention in the post.

    Once done steer the group in a standards setting meeting, try to avoid any “my way or highway” go getters getting to mouthy and use it as an opportunity for everyone to contribute to and educate/be educated. I’ve done this in a few organisations i’ve worked for and more recently my own and it works well. Important to revisit, early and regularly at first because there’ll no doubt be some crap that needs to be changed/removed.

  7. I’ve been quietly mulling this over in my head for a few months now. Over the 1 year I have been employed at my current job, on numerous occasions I have experienced the negative impacts on quality and deadlines when coding standards are not in place or are poorly documented.

    On the flip-side, when interviewing for jobs, I feel a bit of negative tension towards companies that strictly enforce coding standards set by implementing pre-built frameworks. In my opinion, I feel that coding standards are something that should be set on a per-company/team basis. A framework that works great for Ecommerce applications won’t necessarily work well for multimedia applications. This is why it is important to have regular team meetings to discuss what opportunities are available and if it may be necessary to combine a set of standards to best fit the company/team/project.

    I think that what everyone else said about having the entire team’s “buy in” when making any sort of decisions like this, is right on the nose. After all, that’s what being a “team” is all about.

  8. I guess it kinda depends on a few factors:
    – how many people does this apply to?
    – enforcement
    – cost/value

    I recently left my old job for the very fact that there was all this ‘standards’ business going on. Legacy crap trickling down from idiots in suits telling us why we have to use ClearCase over SVN or we HAVE to have some broken DHTML crap on the homepage.

    But in the same respect I certainly embrace standards when it comes to coding, clear down to the packaging schemes. Squigglies are taking it a bit far. I think the larger a team is, the more enforcement is needed. Especially if you have Old School ActionScripters working with J2EE => Flex converts.

    I certainly advocate:
    – code reviews
    – peer programming and design collaboration (i.e. Agile w/ a little “a”)
    – quick daily kickoff meetings to address who’s working on what and why and how better to do so
    – an in-depth review of MVC and Cairngorm and WHY and WHERE you do WHAT (there are plenty of ‘Senior Flex Developers’ out there that still command-delegated tasks on the model?!?!?)
    – an in-depth review of the MX framework especially if you are doing custom component development

  9. Squigglies are a vital issue! I use BSD/Allman, so reading someone using kernel style is always faintly disorienting, plus I keep having the temptation to keep using my usual style when editing someone else’s file.

    You run into a border issue: where’s the border between, say, using variable type prefixes like sMyVariable:String and nMyOtherVariable:Number; and what style of brace indenting you use? If that border seems pretty clear, what about naming interfaces GeneralName versus naming them IGeneralName? Just about every coding style issue has implications somewhere, and arguments either way. I think if you have a code style, you should enforce it down the line — consistency is necessary, even if it’s on an issue like brace indenting, where there’s no real reason to choose one over another as long as you do choose one.

    As for myself, I’m lucky: I’m the lead programmer at my agency, so I get to just write and hand the coding stylebook to new hires as a fait accompli. There’s no need to build consensus, just a “this is our coding style, please use it.” Of course, that doesn’t help with your question…

Comments are closed.