This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Simplicity and Other Dilemmas
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
This weekend I've been thinking again and again about keeping software (and computers in general) simple. It started off with a comment from a BMC co-worker at lunch Friday: an old colleague of his believed that the customer should never be given a choice, the application should choose for them.
Obviously, this can't always be the case, e.g., if the applications supports multiple ways of exporting data, the user will have to choose one of the ways when exporting. However, the bigger thinking behind "don't give users choices" is (1.) users don't want to make choices, and, (2.) users don't know what to choose.
Joel boils this down to "Every time you provide an option, you're asking the user to make a decision":
They do not, however, care one whit if the program's own toolbar is on the top or the bottom of the window. They don't care how the help file is indexed. They don't care about a lot of things, and it is the designers' responsibility to make these choices for them so that they don't have to. It is the height of arrogance for a software designer to inflict a choice like this on the user simply because the designer couldn't think hard enough to decide which option is really better.
"I purchase IT using the same criteria as ultralight hiking: fast, light and robust is better than complex, full- featured and unreliable," he said.
On his fast-and-light IT list is a fervent request for Microsoft to come up with a version of Office that has only those features needed rather than the raft of features being offered in the next version. "We've asked Microsoft to offer Microsoft Office Lite--fewer features with more security and robustness for enterprise customers," he said. "Does the animated paper clip really add value?"
This reminded me of another article about upgrading to Office 2003 (or whatever it is now) I read recently, though I can't find the link: one of the CTO types interviewed pretty much said, "if we could, we'd stick with Office 97, but we've gotta upgrade to work with documents other people send us." Point being: Office 97 worked, and would work, fine for them, there really isn't any value added by upgrading. I suspect this is often the case.
Rational focused so heavily on just the architectural end of this and just the modeling part that they forgot all the guys who had to do the work: the developers. They never addressed that market. That was [Borland's] strength. We also were forgetting the whole modeling and architecture part. But a couple years ago, our developer customers were saying they needed to model their code. Not because they wanted to model and create code, but the developer wanted to create his code and then model it so he could have the architect bless it and sign it and show it off.
I've yet to experience modeling as anything more than code-candy. By modeling, I pretty much mean UML...as there's little else. Certainly, being able to extract a model from already written code is nice, but formal modeling is rarely expressive enough to make communicating with it worth while. Oftentimes, when I'm trying to formally model something, I'd rather draw it on a whiteboard or a piece of paper. I'm not sure if that means I'm just a better doodler than UML'er, but, I'm not sure that improving my UML skills will help simplify anything.
Previous Topic
