Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have a small team (2-3) of programmers writing a program with a lot of forms and dialogs. We have a problem where we cannot keep good consistency in what we write, or how we write it.

The latest issue I've noted is that we have lots of places where we have a date range, and we use all kinds of wording to indicate this range is it Start/End or From/To or "Between _ and _".

The other side of this is that one of the developers might come up with a better way of doing something (like maybe initializing the state of a check box from the settings file). And then we'll have all of the "old" stuff written in the old/poor way, and new stuff written in a better method.

I try to be constantly vigilant about the first thing, but it seems like I'm always finding new failures.

The second one creates a huge burden if we're going to go back and fix all the old stuff as soon as we come up with a slightly better way of doing something. Either that, or we ignore all old stuff until something is broken, and then we have no clue what the heck the software is doing because its written completely differently than what we write currently.

One last thing, if we push the burden of "fix it everywhere now that you've found it" on the developer who comes up with the better solution, its self defeating, because its like great, that's a better way to check for that error, now fix it everywhere in the code.

Bosses don't really ever seem to care about the quality of the code, just when we'll be able to release the next version (but that's a different discussion).

share|improve this question
6  
Your issue may be more to do with the fact you have duplication in the code. e.g. can you extract the date code to one single piece of code that is re-used. –  Alb May 4 '11 at 14:32
    
Possibly related blog post: Strategy vs. Tactics in Coding Standards –  Anna Lear May 4 '11 at 14:38
    
I'm assuming you are talking about web programming. Is this correct? –  Cape Cod Gunny May 4 '11 at 21:43
    
"Bosses don't really ever seem to care about the quality of the code" - most bosses who aren't imbeciles realise that quality is important, but a rational business decision is based on cost vs. benefit. It's a lot more difficult to estimate the likely cost of bugs (in terms of customer goodwill and so on) and of maintenance effort than it is to estimate the cost of writing code, so in the absence of information the rational thing to do is de-emphasise it. They need your help to make a better estimate of the likely cost of neglecting quality. –  Tom W Jun 1 '13 at 10:13

5 Answers 5

up vote 0 down vote accepted

The most important thing for you and your team should be communication.

You might want to develop a common styleguide that defines things like "how should a date range be named". However it's very important that this styleguide is appreciated by everyone on the team. If anyone has the feeling "oh my god, I know how to do my work and now I have this stupid document telling me what to do" then the effort is doomed from the beginning. On the other hand if everyone agrees "yes, that's a good idea, now I know where to check when I don't know how to name a thing" then you'll be a lot more productive.

However such a common belief is established best, when everyone is part of the development process and feels like "yes, I contributed to that set of guidelines". If your programming team is small, as you wrote, then it's the ideal situation.

The other fact will hunt you for the rest of your development life: You will never ever write perfect code. That's been said alread. But you will never ever write code, that when you're revisiting it a few weeks later will still look good to you. Even if you're the only one having touched the code. I always find myself thinking "my god, what the hell have you been thinking when you wrote that piece of crap?". The funny thing is: I know, that I had my reasons for doing something in exactly the way I did - I just can't believe it any more.

You have to accept it, and yes, it get's worse when you're working with somebody else because - let's face it - writing software is like driving a car: nobody can do it better that yourself ;-)

So, you will always have to refactor your software. Fix the things you did wrong in the first place. That's a good thing and totally normal.

Bosses don't really ever seem to care about the quality of the code, just when we'll be able to release the next version

That may be true on first glance. Luckily not all bosses think that way, but even if they do: Code quality has a direct effect on the ability to ship the next version. Bad code leads to more bug, leads to more time needed to fix the product, and so on. The central element here is communication - once again. You have to embrace the thinking that refactoring and introducing better code is an integral part of the development. Refactoring is not just "Oh, this looks better, let's take some time and implement the change" but making the product fit and robust for future generations. This might require some backbone telling another person "No, we can't move on, we need to refactor feature X" but that's part of the job.

share|improve this answer
  • Use inheritance and common objects to store common UI and code in one place so that it can be used throughout the application. This way, if something needs to be fixed, it is fixed in one place and the changes are automatically applied everywhere.
  • Use code analysis to check for coding style and enforce certain ways of writing code. You won't be able to cover every possibility, but it does help. Furthermore, you should agree on certain coding standards amongst your team members and start using them.
  • Don't worry about fixing things everywhere right away. It shouldn't be up to one developer to fix anyway. Everyone on the team should be aware of the "better way" of doing something specific and fix it as they come across it while working on something else. Also, you should allow for some time to refactor your code during your development cycle, which could be spent fixing older solutions to use the newer ("better") ones.
share|improve this answer
2  
Also, if you want consistent verbiage site-wide, look into Resource Bundles. An RB contains name/value pairs of text, you reference the key on the presentation layer. This allows you to re-use and easily replace common words and phrases. –  Adrian J. Moreno May 5 '11 at 11:44

Ask developers and designers to work together to create a style guide for your product, and have developers follow it. Have frequent check-ins as the code is implemented to make sure it matches the spec (in general; the details obviously will change a bit as you hit implementation constraints). Update the spec as time goes on to incorporate desirable changes.

To the extent possible, separate logic and presentation, so that if you decide on a new UX element (e.g., "between $start and $end" instead of "from $start to $end"), you only have to change one String in one place.

Finally, if 'creativity' is really a polite way of saying 'can't follow the spec', have a conversation about that instead. There are places to express creativity, and places to work within the design; inventing new interface elements on the fly leads to an inconsistent, confusing product. On the flip side, consistency is only one goal, not the only goal: sometimes it's okay to have some inconsistency.

share|improve this answer
    
If you ever aspire to make alternative language versions of your app, you'll need all the text strings extracted into a resource file of some sort anyway, so this practice gets you that opportunity, as well as helping with consistency. –  Carson63000 May 4 '11 at 21:29

You need to sit down with everyone and come up with a Styles & Standards guide. Ideally, you want a document containing certain conventions that are common across all parts of the application(s). It can contain naming standards, UI layout standards, etc...

You're worried about stifling creativity, so make sure that the guide is a guide and not a bible to be followed religiously. Certain types of small deviations from the guide should be OK if they are necessary and the team lead should accept it with good justification (the decision shouldn't be left to the developer alone - some review and acceptance by higher-ups is necessary). Depending on how big the deviation is, you might want to talk to management/QA before allowing it, as it may indicate an area for changes in the style guide itself (if it's a large or recurring attempted deviation).

It's also important that there should be a process to change/update the guide to keep up with new techniques, new design ideas, new corporate branding, etc.. just be aware that changing the guide may invalidate old parts of the system so going back and updating the program as well may be necessary at times.

share|improve this answer
    
Be careful with the "not to be followed religiously" part. When you introduce such a guide (and the team buys into it), it's important that it's actually followed. Allow people to bring up changes or do code reviews, but I wouldn't allow unreviewed deviations from the agreed-upon style at developer's discretion. That way lies madness. –  Anna Lear May 4 '11 at 14:37
    
It seems like the style guide gets too large to be followed if you try to have a guide for everything. Also, it seems like you're just being a pest if you point out "you didn't use the proper style on when you did that", please fix. Unless you just go in and clean up the other developers mess every time he does anything. –  David May 4 '11 at 14:48
    
@David: That can happen too. I didn't say it was easy, but if it's done right, it's well worth it. And yes, some one has to be the pest enforcing the style guide. Best to pick one person (probably the team lead, or a QA person - non-developer if you have one) and make it their responsibility to check everyone else's adherence. It's not a popular role but it can greatly ensure consistency, which is the whole point. Unless you think you can trust your devs to be self-regulating. ;) –  FrustratedWithFormsDesigner May 4 '11 at 14:57

Innovation == Disruption.

That's what innovation ("creativity") looks like. It looks like disruptive, non-standard, non-compliant, new code.

Here's the obligatory quote:

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.

Here's why that's important.

Focus on Value

Simple consistency may not have any value.

we have lots of places where we have a date range, and we use all kinds of wording to indicate this range is it Start/End or From/To or "Between _ and _".

How does fussing over this this create value? Who is helped? How much is it worth?

How much does it cost to leave it alone?

Consistency is not a direct quality attribute. At the very best, consistent code might make maintenance or adaptation easier. But for the most part, it's of very little value.

This isn't really very innovative, so it doesn't much matter.

one of the developers might come up with a better way of doing something ... And then we'll have all of the "old" stuff written in the old/poor way, and new stuff written in a better method.

So?

What's the value in retroactively changing a lot of code?

Is the cost of searching and replacing really appropriate for the value created?

What's wrong with changing it eventually?

Code comes and goes. Code gets reworked all the time. Some code may get deleted (because it's no longer used) instead of changed to be consistent.

Innovation means that you have legacy code that's being slowly evolved to the new form.

If you value innovation, you have to value change and the disruption associated with innovation.

share|improve this answer
    
+1 for focus on value alone... –  user2567 May 4 '11 at 15:13
    
It can be more trouble to judge the "value" sometimes than to determine the consistency. Here's another case... we print out pages, sometimes out of the report engine, and sometimes non-report pages are printed. It certainly has a value to have each page of each report have page numbers. If you're not in the habit of maintaining consistency, how are going to remember to check that this Print-out has all of the little things that might be easily forgotten (like page # or printed date). –  David May 4 '11 at 15:32
    
@David: "how are going to remember to check"? That's what unit tests are for. –  S.Lott May 4 '11 at 15:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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