Ideas are easy. I've got dozens. Marketing is hard, it's why I'm not a millionaire. In this case I wrote the app for myself, after having an extended text conversation where a girl I really wanted to talk to was texting me at odd intervals while I was driving, forcing me to stop every two miles and pull over to respond.

Agreed, its better not to text at all. You're at least somewhat distracted when you do. But lets face it, some people won't do that. My belief is to lower the danger as much as possible for those who insist on texting, and since you keep your eyes on the road I do believe its safer.

As for homophones- voice dictation software these days operates on a sentence. 99% of the time you can differentiate between those words based on context. For the 1% you can't, you flip a coin and possibly send the wrong one. Hardly the worst autocorrect mistake you'll ever make. I'd bet on making fewer mistakes with a readback prompt than you make in normal tapping.

It launches itself when it detects an incoming text. In Android you can declare a class (a subclass of BroadcastReceiver) that will have a function on it called when the OS detects certain events (like incoming SMSes). The motion detection algorithms launch at boot.

I wrote my own hands free texting app, that automatically determines when you're driving (based on speed). It solves this in a very simple way- after you speak your response, it repeats it and asks if you're sure you want to send. If you say no, it lets you re-enter your response. No need to look at a phone at all.

Cheap plug: Text Soundly is available at the Play Store here.

No, you don't realize you suffer from it. You won't until it accumulates to the point you need corrective glasses.

Do you understand the concept of long term eye strain? Its not a matter of just getting a headache or eyestrain on a given day- there's cumulative damage from staring at a screen all day.

Tablets are horrible for reading ebooks. They smudge easily, they strain the eyes, and the battery life won't support reading for an extended period. An e-ink reader is orders of magnitude better.

And at no time did you realize that it's the completely wrong tool to use for that and that there's better and easier ways to manipulate that kind of data (if you even need it, most of those intermediate data points will never be used)? Wow, that's grade A level incompetence there.

You mean it would allow people to install applications they want on hardware they own? The horror.

You're assuming the client wants to be involved that hands on. Most don't. They want to see a prototype every now and again and that's it- they don't want to be involved in every meeting about feature prioritization etc. Remember that this isn't their job- they have other things to do to actually make money.

And while developers lack knowledge of the target domain, the customer lacks knowledge of the software domain. Involving them in every decision just makes them feel stupid, clueless, and frequently they make the wrong decision. Its not as cut and dried as you'd like.

THat's the same with any methodology- if they want a change you scope it out and give them a number. Agile is no better or worse at it. If anything the numbers tend to be a bit higher because of the tenet of not working on anything that isn't needed immediately, whereas when you design up front you tend to design in some flexibility for likely future changes/usecases.

Hey, it's Mr. Strawman. I haven't seen you in days!

First off- waterfall doesn't exist. It never has. It was made up as an example of what people thought development was like, and then immediately used to contrast with how software really was made. Really- check out the history up front.

Secondly, nowhere did I say waterfall was the preferred method. THere are more than 2 options here. Shocking, I know.

Agile is absolutely not about providing information to make decisions early. By the point that you get enough functionality into an Agile project to make any non-trivial decisions on projects of non-trivial scale, you're already many months in and have an architecture that changes will force you to throw away. You're going from possibly needing to throw away work due to changes to assuring it. The costs are no less, and actually tend to be higher than other forms of iterative design.

THat's great, if you're writing something that's highly customer visible and understandable, like a UI. If you're building a front end webpage, go agile. If you're writing a back end set of service or algorithms, the customer won't be able to see anything, and won't be likely to understand it even if they do.

With traditional methods, you have some possibility X of major change towards the end. The value of X depends on how good your engineers are at design and requirements gathering. The cost depends on exactly what the change is and how good your devs did with design. With Agile, X is 100%, and the cost tends to be fairly high because there is no design and no effort put to possible future use cases or changes up front.

Yes. Java is a language. If it compiles and runs programs written in that language, it's Java. That would be like claiming that rvds binaries aren't C because the binaries it puts out won't run on x86. The VM is 100% immaterial. Hell, you can compile Ruby and Python and run them on the Java VM, does that make them Java?

2-3 meetings a day? When the hell would you find time to get things done? And daily 1 on 1 meetings each day with the manager might be needed for junior devs, for senior devs you're just getting in the way. Remember the important part of the idea of daily meetings isn't talking to your manager, its talking to your peers.

I'd rather see 1 longer meeting a week, and you email/talk to whoever's blocking you as needed. I find that there's almost nothing of real value discussed in the dailies. Maybe 2, more than that is wasted.