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.

Our team supports BackOffice application: a mix of WinForm and WPF windows. (about 80 including dialogs). Really a kind of a Swiss Army Knife. It is used by developers, tech writers, security developers, testers.

The requirements for new features come quite often and sometimes we play Wizard of Oz to decide which GUI our users like the most. And it usually happens (I admit it can be just my subjective interpretation of the reality) that one tiny detail giving the flavor of good usability to our app requires a lot of time. This time is being spent on 'fighting' with GUI framework making it act like we need. And it very difficult to make estimations for this type of tasks (at least for me and most members of our team). Scrum poker is not a help either.

Management often considers this usability perfectionism to be a waste of time. On the other hand an accumulated affect of features where each has some little usability flaw frustrates users. But the same users want frequent releases and instant bug fixes. Hence, no way to get the positive feedback: there is always somebody who is snuffy.

I constantly feel myself as competing with ourselves: more features -> more bugs/tasks/architecture. We are trying to outrun the cart we are pushing. New technologies arrive and some of them can potentially help to improve the design or decrease task implementation time but these technologies require learning, prototyping and so on.

Well, that was a story. And now is the question:

  • How do you balance between time pressure, product quality, users and management satisfaction?
  • When and how do you decide to leave the problem with not a perfect but to some extent acceptable solution, how often do you make these decisions?
  • How do you do with your own satisfaction? What are your priorities?

P.S. Please keep in mind, we are a BackOffice team, we have neither dedicated technical writer nor GUI designer. The tester have joined us recently. We've much work to do and much freedom concerning 'how'. I like it because it fosters creativity but I don't want to become too nerdy perfectionist.

share|improve this question

closed as too broad by Ixrec, GlenH7, durron597, MichaelT, Snowman May 28 at 19:00

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer 1

up vote 4 down vote accepted

Step 1) You need to get the users of the product clamoring to management that they need more of your development time and so that they can have the UI tweaked just the way they want it.

Tweaking the UI to perfection is a notoriously time consuming activity, and your issues in this regard are pretty typical. But it's not your battle to justify the required time to management, it's the Users' job to do so. In essence, they need to plead to management and persuade them that investing X time in Y feature benefits the company. Not your argument to make, it's theirs.

Hint: This is how you balance some of the pressures you mention in the first question.

Step 2) Start consolidating / migrating on fewer UI technologies. The no-brainer choice is to migrate towards WPF. It's easier to get the whiz-bang functionality from WPF as opposed to Winforms, and WPF will receive more updates than Winforms ever will. No, you didn't necessarily ask about this part but you need to consolidate in order to get better at creating your estimates.

Even a line in the sand of "all future development shall be WPF" is a step in the right direction.

Hint: This is how you gain credibility with your estimates which will help you with balancing multiple, conflicting pressures.

Step 3) Learn to negotiate for "good enough." We all want perfection but it's a very expensive state to achieve. Learning to get by with good enough is the key to your second question. How often do you do that? On pretty much every single requirement....

Truth be told, perfection is gold plating. It's awesome. It's really pretty and nice to look at. But most of the time? You and the users don't need it.

Once you accept the reality that there is more work to accomplish than can be done, you start to recognize the gold-plating, er perfection, for the time sink that it is with a corresponding low benefit-to-effort payoff.

Step 4) Recognize that you're not paid to create perfection. No, you're really not. You're paid to meet the needs of your users. Understand that there is a tipping point. Nailing one requirement really, really, really, really well is honestly not as good as nailing four requirements really well. The medical field uses the term "triage" for situations like this. You take care of the urgent priorities first; stabilize them; and quickly move to the next most urgent priority. No, you never get a patient back to perfect health in that situation.

There is a phrase (or a Kōan) that says "Better is the enemy of Good." And the initial interpretation to work with is that it's always possible to make a solution "better." The key is in identifying what is "good enough."

share|improve this answer

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