Don't forget that you have to deal with existing messages, which may be longer than 140, and may be truncated in your new views/layouts, making history unpredictable.<p>Don't forget that you're going to want to add attribution to the SMS, so you really have less than 140 characters.<p>Oh, and don't forget that you are going to drastically decrease the value of a percentage of your reviews, which would have previously been long, detailed, and useful.<p>The complexity of any modern day advanced system makes even these tiny changes balloon. The worst part isn't even the expanded work, it's the inability to predict how long all the ripples will take to fix.<p>The subtle bugs that got introduced by a "tiny cosmetic change" are more easily fixed in a web environment, but become pretty devastating when you have a slower release cycle, or someone gating your releases (like Apple).
I'm often a part of the design sessions at my work, and all the questions that look like so much in text are covered in an audio chat in 5-10 minutes, and for something like adding an error dialog and character counter, another half an hour turnaround from our designer for the graphics. I'd say any feature that takes less than an hour to design is a small change.
I often hear programmers announce how they did something in minutes that would have taken me days. I'm going to keep this on hand to cheer me up on such occasions.
On the message front, I have learned by now to always ask the client or marketing for the text up front. Why? Because it doesn't matter what you pick as the developer, they will want to tweak it because that's the only thing they have power over. Might as well get it over with first.
Why should the SMS use case limit the general use case? If someone wants to submit a review by SMS (really?) then they can deal with being limited to 140 characters. Problem solved.