How to deal with design-freaks?

Question

A workmate of mine really loves designing for each and every use-case, no matter how unlikely its occurrence will be or if it's even in the scope of the project.

As a result, some of us are having some kind of trouble weeding out unused interfaces and finding out what data field of an interface is actually used.

Do You know similar cases and how to deal with those guys without demotivating them?

---

[edit]

Thank You for Your answers so far. I guess, some of You may wonder why I could not figure out how to deal with this issue by myself. Therefore, let me add some details to clarify things:

• We do not work on the very same project, but our projects are tied together. Therefore, I cannot tell him to stop or cut down on his design (he's responsible for the design of his project).
• This is also why I am not able to track every of his moves.
• We are designing and implementing for our research lab, therefore I cannot play the "customer pressure" card.

Answer 1

Have you asked your workmate to stop? You don't have to be rude. Or you can ask he/she to give you the most common use cases from their pile of designs and leaves the "extra work" to them.

Answer 2

Have him write test cases for the stuff he adds, and have him to execute them as well.

If it does not fit his job description - persuade him to do this at least once ("to get a better feeling of blah-blah-blah").

Answer 3

Story-boards are good for showing the pathways through common tasks and thereby identifying the key interface pieces. In conjunction with the requirements - and the QA team if you want to really do it properly - you should be able to come up with a set of story-boards which will inhabit the middle of the feature set of the product. The priority of features will show itself.

Tools for story boarding range from fairly sophisticated prototypes to pens and paper. My experience suggests that pens and paper are a really quick way of starting and then allow you to fill in with screen grabs from the designer. It's also fun to cartoon your product in a brain-storming session. We had a wall at the end of the office on which we would pin our story boards.

It also turns into a very good tool for tracking progress , showing progress and direction to the boss and for general group awareness.

Answer 4

Agile methods. Look at practicing Scrum or XP or something similar. Apply the principles of putting emphasis on delivering business value early. Have the customer choose what features to implement and deliver early and often. You'll be so busy working on delivering code you won't have nearly as much time to "gild the lily."

At the very least I would have him, instead of implementing something as it occurs to him, have him add it to the back log and let the team decide which things get worked on.

Answer 5

Start having conversations with them about lean designs. That elegance in designing anything is in being able to create something with just the right amount of design while keeping things as simple and as elegant as possible

TDD helps with this...

Design reviews / retrospectives helps with this...

Huge confidence in your ability to refactor help with this....

Experience helps with this....

One of the difficulties of learning this stuff is you often need to over design and under design things to learn what the "right" amount of design is. The problem with that of course is that often ends up painful for everyone else while you are learning these things.

But the way forward is feedback / communication / constantly talking and "debating" design ideas.

Answer 6

Get him to into Unit Testing so he can focus his meticulous energy into that. ;)

Answer 7

You can try and ask him nicely to cut back, but you do need to try every conceivable use-case (ideally). Maybe have him write unit tests; that seems like it would be more what he wants to do.

Answer 8

Oh no! you are seeing an anti-pattern, a golden hammer for a design freak. This is normally seen in people who have just learned new things and try to apply it everywhere. Not restricted to general programing, this also shows up in HTML/CSS designs where it is termed as classitis or divitis. The solution for general programing, is to ask him/her to think interms of interface consumption, come up with justifications (that is the recommended/standard way is not allowed, a description in layman terms is sought). Also asking the person concerned to think of alternative solutions before he/she begins babbling, makes them comeup with intelligent points. Tell him to look for 'beautiful' solutions not workable ones. That would keep him/her occupied for sometime, let the caterpillar evolve into a butterfly.

Answer 9

Very simple.

Ask him to gather all use cases he has designed, and rank them on a scale of 1 to 4 starting with

1. Will definitely occur. Customer has specifically requested for this.
2. Will definitely occur. Implicit use cases like Authentication or Logging of user activity. But customer did not ask for it specifically.
3. Should occur. These use cases must be incorporated in order to meet certain coding standards, security requirements and other such compliance issues.
4. Cannot occur. Customer did not ask for it. This not an implicit requirement. This is not needed to fulfill any compliance audit either.

Now that he has ranked all use cases, he will himself realize, that he may be wasting time with a lot of Type 4s.

Answer 10

Based on how you asked the question, I'm guessing the person is a peer.

My favorite approach to this kind of problem is to be so good at what I do, that the person comes to me for advice. It takes time, and effort - but no matter what happens you always walk away better for it.

If you don't like where the bar is set, set it yourself.

The problem with many of the other sugestions, while all very helpful and probably correct, is that you probably don't have the credibility or authority to do any of them. Without that, you will simply be percieved as someone that "doesn't get it". There is a big difference between a person that is considered to be the top dev on the team telling you that you are a victim of anti-patterns, and some random person saying your code is difficult to debug.

/// ===== Edit

I was looking over my answers as I was taking a TDD class. A couple of points: 1) It is considered bad design to add functionality that isn't needed 2) Have the person use TDD. If the person is a design freak, the first principal should be a concern to him, and the second - if done correctly - will improve their design and make it easier for everyone else to figure out the code ...

... going back for more cool-aid -

Answer 11

All use cases should be written down somewhere. Depending on how important they are, the amount of detail varies -- from a fully-dressed use case to barely more detail than a descriptive name. Like others here suggested, the key in not getting stuck in over-specifying everything in the world is to give the "brief" treatment to everything, and then choose the most important UCs to elaborate on. Every iteration only touches the tip of the UC iceberg -- and this doesn't just pertain to implementation, but also to use case elaboration.

The trick in ranking which use cases to work through is to evaluate their importance -- but I have to disagree with some of the folks here who have suggested that the ranking should be based on the difficulty of writing Unit Tests, or on "did the customer ask for it."

Two factors that should be considered when choosing which use cases to elaborate and to work through first:

1. Feature importance. The customer can provide some ranking guidance.

2. Risk. X happens rarely, but when it does, patients get irradiated with lethal doses of radiation. That's probably really important even if it's not likely to happen. Customers often do not have enough information to evaluate risk, and pushing this onto them is not agile development, it's shirking responsibility.

It needs to be understood by every member of the group that not all use cases will be designed in detail in any given iterations -- just the top ones. Everything else is important, too -- and it will see the light of day next week.

Edit Having read your update to the question -- research labs have goals, too. It's easier to get sidetracked when there is no paying customer (other than NSF) watching what you are doing, but you still need to do the research, publish papers, present at conferences, discover something (or discover that the something doesn't work). So your question becomes not "did the customer ask for it?" but "is this critical to the problem we are trying to solve?"

For example: Him: 'we need to code resilience into the system, since if the power goes out, we have to spend an hour recovering otherwise." You: "how often does the power go out? Can we recover as things are right now, or do we risk completely losing all research for the past 6 months? Is our research on recovery and resilience, or on better fudging of pudgy widgets?" ...

Answer 12

Make sure this person has a clear deadline for finishing. The deadline should be reasonable for getting done what needs to be done. People soon start doing tasks in the right order and doing just what is needed when under pressure.

Answer 13

Let him understand negative consequences of such design approach. You already mentioned unused interfaces etc. I'm almost sure his solutions are overcomplicated, which leads to more time spent understanding and modifying it. It may also lead to more bugs. I'm almost sure it leads to more bugs. But I don't know if you have enough evidence to convince him.

Anyway, don't forget this aspect: it's not only waste of time. It may negatively affect quality.