|
There are several rules I must keep asking programmers to follow very often. They write code and, if it works, job is just done, for them. Most basic rules might be:
Can you tell me about your experience? How do you manage this? |
|||||||||||||||||
|
|
All knowledge workers need to be challenged to do quality work. Quality will suffer if they feel arbitrary time constraints are placed upon them. Why not just make things that are "good enough" when everyone is concerned with fulfilling the specifications and meeting the deadlines? Your list of complaints are symptoms of a company that only rewards meeting short-term objectives and has no desire to emphasis high quality. Are you running a five-star hotel or a truck stop? |
|||||
|
|
To be able to follow the basic rules, they need to know what the rules are and they need to agree with them. The way to handle this is to jointly create a coding guideline document which everyone can agree with. Don't try forcing this on them, it will backfire if you do. So get the team together and start working on a common definition of your basic rules! Do it as a workshop where all voices are heard. Timebox it to avoid endless discussions. You are trying to bringing several minds together, so you may want to set the stage with a positive note that you all should be respectful and keep an open mind (code writing is personal...). These guidelines should be alive changed whenever the team feels there is something that should be added or clarified. |
|||
|
|
|
What is your role? If you are just another developer with a particularly strong interest in code quality, you probably don't have the authority to get them to listen to you, and maybe you should bubble up these ideas to management to establish code standards that should/must be followed. If you are a manager/team lead/architect whatever and you do have some authority, then you can establish those practices yourself. Institute a standards document and a code review process to weed these things out. It is not going to be a magic switch that you can turn on; it will be a slow process and will never been 100%. That's been my experience anyways. |
|||
|
|
|
Code review. Accept only well written code that has no errors. |
|||||
|
|
It needs to be a sensible combination of all of the answers so far. In the end, when you're talking about a group of smart people (developers), you have to give them reasons why the behavior is important and give them enough control over how that behavior is implemented that they are invested in doing it right. Mandates from above are generally a loose with smart people, because if they have not agreed that the problem is a problem, then they are likely to spend more time working around the mandate than following the rule. Here's a few of my tactics: Committing Changes: First, the team needs to agree on when to commit and what to commit. Absolutely essential is a build setup that makes sense, so that people aren't holding off just because they don't know where to put something. And a consensus on when/how often to check in. "don't break the build" is an obvious good rule, but how is that checked, and who gets told about it? Another baseline is "it's not done if it's not checked in". Most developers I know are more than happy to check in code IF:
One thing that I noticed recently was that checkins got more frequent and less painful when we lept forward to a new CM tool. Our team is pioneering Rational Team Concert having formerly used Clearcase. I don't mean to advertise tools, but the new (to me) wave of streaming checkins with lots of small, fast merges makes it way more enticing to checkin early and often. Letting developers be in charge of eliminating CM pain generally increases the amount of checkin in that happens. Adhering to Architecture - Not Writing Model Issues in Views and Controllers I'm putting that in the general clump of "do the architecture correctly". I agree with whoever said peer reviews - peer pressure is great for this. One of the ways I generally see people come into the fold for best practices in this area is when their peers ask them why they did it the other way (the not so right way). Generally the "why" question will lead people down the path of realizing for themselves why they should have done it differently. When people have a well understood reason for the best practice, it's much easier to adhere to it. Also, if there's some formality linking a person to a decision, then it can be easier to assign bugs in that area... so if a person is responsible for fixing bugs in an area of faulty design, the need to get something right before they can move on to something new and exciting can be a big motivator. Avoid Hardcoding I'd start with clear coding standards and integrating a coding standard review in peer reviews. Hard coding is one of those things that can easily be a checkbox on a peer review agenda. I'm afraid that this sort of thing is the one thing where I've seen it become the role of the team lead to enforce the rule. In teams I've run, we generally won't let someone move on until they've fixed the comments from a peer review of their code. And "no hard coding" is a frequent peer review comment. In general With almost any best practice, I think you have to pick your battles. No team will become absolutely perfect. But you can keep an eye on your major pain points and start tackling them in clusters. I think it becomes the role of the leader to really know what is a pain point for the team vs. an annoying quirk of a particular individual. If your team is missing out on doing a particular best practice, I think the first question must be "how much damage is this causing?" if the answer is "minimal", then it's probably not worth the time. Some best practices are most relevant to specific types of systems - while they are good overall, they may not be worth the battle for systems where the practice is not a frequent occurence or major part of the system. If the answer to "how much damange?" is "ALOT!!!", then you can start building a case for showing the team that all this pain and suffering could be removed by fixing this one slacking point in best practices. Most people are happy to avoid pain and suffering and it changes the dialogue from "do this because I told you to", to a "we decided to do this because it's better". |
|||
|
|
|
At least :
Besides that choose what works based on your organisation, the developers and your role within the team.
|
|||
|
|
|
Thanks for the answers. I just cannot vote up or re-comment as my reputation is too low here. My role is Manager, but as a small team I do develop and I rather prefer to manage as a coach. Electrodes in the chair connected to a code parser has already been pointed out, but programmers don't seem to be afraid. Firing does not sound as a good approach, as that means loosing worthy assets. I'll take a look to all those tools and I remain open to any other you tell me. |
|||||||||
|
|
There are 3 ways by which we address this issue:
|
|||
|
|
|
Here's my 3-step plan:
:D In all seriousness, if they don't believe in doing anything but writing code you need a more well-rounded team. A programmer where I worked used different directories on the computer as her CM. We fought with their programmer for almost a year (as changes would introduce bugs as they copied and pasted old code). We eventually just fired them. |
|||
|
|
Alternatively, the most cruel but very persuasive thing to do is let them maintain an extremely poorly written codebase, given a tight schedule. :D Generally, the unwillingness to adapt certain standards means a lack of experience in team work. In the end people only learn from mistakes. NEVER fix problems, that are based on someone else's stubbornness. If it is really vital for the project (i.e. your company will be sued if you you don't deliver within N days), then put them off the project first. |
|||
|
|
|
I think you programmer won't change their attitude towards these issues you've mentioned until they realize that those things will lead to a benefit or advantage for them. Try to explain them why you want them to do these things. Even better, let them experience the advantages. |
|||
|
|
|
Hire one professional Software Engineer. And then fire weakest. Then slowly replace those who can't adopt. Having such people sometimes bring more harm than profit in long term. Main idea here, that professional will start doing most job, and firing others will not reduce valuable human resource. |
|||||
|
|
It's a little gross, but I left Code Complete in the bathroom for a few months. Not sure it was effective, but it seemed like a good idea at the time. |
|||
|
|
|
So what are the consequences for not following the rules and rewards for following the rules? If the answer is the same--nothing--good luck getting any traction. I suggest a tiered approach. First get them together and discuss whether they buy into the rules. The next step is to include them in code reviews. You can also try carrots and sticks. Something like anyone who leaves a file checked out overnight has to bring donuts to the next weekly meeting. A carrot could be anyone who follows the rules for a whole month gets a weekend in Vegas. For two. Or fire the worst offender and let the rest sweat it out. |
|||
|
|
|
Make them suffer the consecuences you want to avoid by using those rules, it is the only way they are really going to understand why you are asking, e.g.: make a small controlled mess that they have to correct. |
|||
|
|
|
If this crew is really having trouble checking in changes, adhering to separation of concerns and not hard-coding magic constants then I would fire the whole crew and replace them with real programmers1 that actually care about their craft as soon as possible. Be that one at a time or en masse I couldn't say but these jokers have got to go. The sort of coding that you are describing is suitable for throw-away, one-use-only scripts. It is not how one builds a real application. If they are getting paid as professional programmers, then it is their job to know this sort of thing. 1 This is often used as a joke term for imaginary people that write their code directly in binary or something equally ridiculous. Here, I'm not joking. I'm a fairly rookie programmer and I wouldn't need to be told these things because I care about my craft. These are not real programmers that you are dealing with. |
|||
|
|
|
A manager's job is not to be the friend of the employee, sometimes you have to be the bad guy. Enforcing coding standards and commits, refusal to follow proscibed architecture, failure to use prescribed tools etc are the times when you have to be unpopular. Express the policies clearly. Do formal code reviews and check to see if policies are followed. Do not permit them to move to another task until all issues from code review are adjudicated. If the policy is concerning not commiting code, this calls for a written warning if they cannot do it when they are asked to do so. If they are not committing code, as far as you are concerned they haven't written any. If they don't improve after being given a reasonable chance to improve, fire them. Unprofessional developers are a drag on your team no matter what kind of code they write. They are affecting others with their lack of professionalism and it is not to be tolerated. They are not good people to retain in any event. Good developers commit their code, good developers follow architectural decisions even if they don't agree with them and good developers don't hard code. You won't be missing anything except headaches by getting rid of cowboy coders. |
|||
|
|
