This is often the result of a lack of domain expertise or “domain confidence”. Developers often see the customer as the domain expert and so they aren’t confident to make hard decisions on their behalf. We’ve all heard the refrain, “just let them decide how they want it” far, far too many times.

There is nothing wrong of course with respecting your customer’s expertise but customers don’t want to be overwhelmed with configuration options. While it can be easy to justify why you’d want to give the user an option for any isolated decision, the collective weight of all the decisions pushed to the customer can be crushing. I agree with Joel that the vast majority of user options represent a missed opportunity to make a hard decision that would benefit the user and the software.

I think that this is also a result of developers having a tendency to push the hard decisions onto their users rather than committing to making those decisions themselves. You mentioned Joel Spolsky – I think he’s talked about this as well, that most “options dialog” checkboxes represent a failure of the designers to make a decision.

I like the word “opinionated” here; that pretty much captures this idea of taking a design stance and committing to it.

Thanks for the feedback. We’re really working diligently to make sure Mingle’s abstraction is more manageable, and hopefully we’ll address a lot of your concerns in the coming releases. In terms of wanting more from ThoughtWorks’ experience, we’ll work to put more of that into the product. That’s both an insightful and humbling request. We’re working on it, and hopefully, we can meet your expectations. Feel free to contact us with more of your thoughts, especially if they can improve your experience.

Regards,
Chad

I’m not entirely sure that having a strong opinion that it’s best not to have a strong opinion is really valid… maybe it is, I’ll have to think about that a bit more.

I did not come to use Mingle as my example lightly. It was a tough decision because I think Mingle is a great tool and I do use it myself. It is because Mingle is so good that it pains me that it could be made much better. I actually stood outside your booth at RailsConf and talked to a stream of developers over a 15 minute period of time. To a person they related what a shame it is that such a great tool as Mingle is had to be just that one extra bit too abstract, complex and complicated. People love Mingle, but it does throw out a lot of abstraction and complexity. Hopefully that is something you are working to reverse as you say you are.

I guess what bothers me the most is when you say you have the experience from hundreds of Agile projects over 8 years. That’s invaluable! I want to benefit from that! Yes, PLEASE! I just don’t feel that I’m getting the benefit of that learned opinion when I use Mingle. You can argue that flexibility is what your customers want but I’ve been on numerous teams that have decided to use Mingle and every one of them felt very unsure that they had configured the tool to an even adequate level to get the benefits that might be available. It’s a nagging doubt that’s never really gone away. I’d be working on that if I were at ThoughtWorks.

Thanks,
Sean

You said, “Your software must interact with its users in a concrete and opinionated way.” We actually have a very strong opinion in Mingle — it’s that there is no one way to do Agile software development. So the concrete interaction mechanism we’re pushing is akin to a spreadsheet. I wrote a blog post about the problems with Agile project tools that aren’t really agile here before we launched the product. Building in one methodology is conceptually contradictory in terms of giving teams the tools to be “Agile” and adaptable. Over the last 8 years, we’ve run hundreds of Agile projects all over the world, and while there are some essential best practices, we’ve realized that flexibility in tool support is a huge win.. We recognize that flexibility and power bring some usability concerns with them, and we’re actively working to make Mingle even easier to use.