I recently was struck by an idea while debugging. Why can’t I click in the code margin while debugging in Eclipse and add a “print point?” A print point would be kinda like a break point that doesn’t break. Instead it prints. You simply specify an expression that evaluates to a string which then gets printed on the Eclipse console each time the print point is reached as the program executes under the debugger.
Sounds like a great idea, right?
Wrong. This idea is apparently not open to immediate discussion in the Eclipse culture. The quick response from the Eclipse group was round rejection of the whole idea:
“This has been asked for many times before. You can easily do this now by adding a condition to the breakpoint that outputs text and returns false so it does not suspend execution.”
Although this is quite cool and a good thing to know (if you can remember how it works), I don’t really see this as the feature I requested at all. While it produces the same result, it does not have the same usability. In fact, if it’s so “easy” to do this in terms of the user experience, why has this “been asked for many times before?”
And although it also leaves Eclipse worse off than it might otherwise be, maybe we can all learn a little something from this:
Just because your DESIGN can do something doesn’t mean that your USERS can.
I leave you with a great TED talk from Timothy Prestero on the subject of design. While it’s not specifically about software design, everything he says applies at least doubly to software designers because we seem to be so much poorer at understanding the context that our designs will exist within than the average group of designers.