How do you get consistency in source code / UI without stifling developer's creativity?

Question

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).

Answer 1

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.

Answer 2

• 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.

Answer 3

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.

Answer 4

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.

Answer 5

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.