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.
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'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.
It frequently is. It doesn't matter what methodology you use- if you change major features/priorities at the last minute it will cost multiple times as much. Yet frequently customers expect it to be cheap because "we're agile". And by accepting that change will happen you don't push the customers to make important decisions early, ensuring that major changes will happen, instead of just being possible.
Interesting breakdown. Scalia joined 3 of the 4 liberals (Ginsberg, Sotomayer, and Kagan. Breyer broke with the liberals and voted in favor of the opinion. It also means a rare moment where Thomas didn't vote in lockstep with Scalia.
We tried that. People were dieing from unsafe food products- meat that was slaughtered in unsanitary conditions, alcohol that has gasoline and other non-edible fillers added in, and crooks who just plain lied about what was in their product. Read Upton Sinclair's The Jungle sometime.
Foo and shelter for the poor? Non-government efforts have been attempted since pre-Roman times. They all failed miserably- people would literally die of starvation in major cities. Now we have government efforts. They're not perfect, but they work- the starvation in western civilizations is damn near zero, the remainder being child abuse cases.
Defense- please tell me how you're going to self organize for defense against an opponent that can kill you by tens of thousands from a continent away, and pay for this effort? Oh, and please tell me how you'll do this without creating an organization that will just take power.
Roads? Well since we never prevented anyone from building them, the US must have a had a sweet set of private roads for cross country travel before the government stepped in and fucked them up. Oh wait, it was the exact opposite- the government was needed to build and finance the interstate system. In fact, there's been no time in the history of the world where an extensive network of private roads was made adequate to the nation's transportation needs.
Step the fuck out of fantasyville and into the real world.
The problem is VAT is a sales tax. Sales tax hit those who spend more of their income harder than those who spend less- they're the most regressive form of taxation there is. That's the exact opposite of what taxes should do. What we ought to do instead is actually prosecute tax frauds, reduce loopholes in the tax code, and make investment income tax at a higher rate than earned income.
Yes, it did. Thats the way most firmware works. Even those projects with an embedded OS end up working like that, unless you want to redefine runtime to mean an OS itself.
The one true video game god, Miyamoto- Donkey Kong, Zelda (all of them), Mario (all of them), and half the rest of the nintendo catalog.
But these are few and far between. Normally when you see a game hyping their lead designer, its a doomed project. It means they don't have enough ideas to hype them instead. And at the same time it raises the expectation levels. Bad combo.
Not every C program requires OS initialization. I've written firmware, OSes, DOS apps, and even unix apps that did nothing- just jumped straight into main. C does not have a runtime. You can add one in, but by language default there is none. Nor have I ever heard of anyone calling library initialization a runtime before- I don't think you understand the term.
Heard of Ouya. I expect massive failure, on the Ngage scale. Don't know anyone who wants one. Gamestick isn't even getting enough press to make the radar. Neither of them will get anywhere near the big console makers.
Androids aren't gaming consoles to compete with xbox/ps/nintendo. They're portables that compete with the DS et all. And developers writing Android games are targetting phones and tablets which are 99.9% of the android world, writing games that work with the built in input methods- basically touch screens only. Absolutely nobody is writing Android games assuming you're going to attach a bluetooth gamepad or keyboard.
Slashdot Mirror
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.
It frequently is. It doesn't matter what methodology you use- if you change major features/priorities at the last minute it will cost multiple times as much. Yet frequently customers expect it to be cheap because "we're agile". And by accepting that change will happen you don't push the customers to make important decisions early, ensuring that major changes will happen, instead of just being possible.
Interesting numbers. Do you have a source, and anything over a longer time period?
Interesting breakdown. Scalia joined 3 of the 4 liberals (Ginsberg, Sotomayer, and Kagan. Breyer broke with the liberals and voted in favor of the opinion. It also means a rare moment where Thomas didn't vote in lockstep with Scalia.
But it compiles Java code and has a big chunk of the Java standard library. I'd call that Java, I don't care what type of VM its running on.
Wouldn't that basically be Dalvik? Just work on adding the missing libraries.
We tried that. People were dieing from unsafe food products- meat that was slaughtered in unsanitary conditions, alcohol that has gasoline and other non-edible fillers added in, and crooks who just plain lied about what was in their product. Read Upton Sinclair's The Jungle sometime.
Foo and shelter for the poor? Non-government efforts have been attempted since pre-Roman times. They all failed miserably- people would literally die of starvation in major cities. Now we have government efforts. They're not perfect, but they work- the starvation in western civilizations is damn near zero, the remainder being child abuse cases.
Defense- please tell me how you're going to self organize for defense against an opponent that can kill you by tens of thousands from a continent away, and pay for this effort? Oh, and please tell me how you'll do this without creating an organization that will just take power.
Roads? Well since we never prevented anyone from building them, the US must have a had a sweet set of private roads for cross country travel before the government stepped in and fucked them up. Oh wait, it was the exact opposite- the government was needed to build and finance the interstate system. In fact, there's been no time in the history of the world where an extensive network of private roads was made adequate to the nation's transportation needs.
Step the fuck out of fantasyville and into the real world.
The problem is VAT is a sales tax. Sales tax hit those who spend more of their income harder than those who spend less- they're the most regressive form of taxation there is. That's the exact opposite of what taxes should do. What we ought to do instead is actually prosecute tax frauds, reduce loopholes in the tax code, and make investment income tax at a higher rate than earned income.
Yes, it did. Thats the way most firmware works. Even those projects with an embedded OS end up working like that, unless you want to redefine runtime to mean an OS itself.
The one true video game god, Miyamoto- Donkey Kong, Zelda (all of them), Mario (all of them), and half the rest of the nintendo catalog.
But these are few and far between. Normally when you see a game hyping their lead designer, its a doomed project. It means they don't have enough ideas to hype them instead. And at the same time it raises the expectation levels. Bad combo.
Not every C program requires OS initialization. I've written firmware, OSes, DOS apps, and even unix apps that did nothing- just jumped straight into main. C does not have a runtime. You can add one in, but by language default there is none. Nor have I ever heard of anyone calling library initialization a runtime before- I don't think you understand the term.
Wow, you mean the firmware program I wrote least week that went on bare metal had a runtime?
Try again.
Heard of Ouya. I expect massive failure, on the Ngage scale. Don't know anyone who wants one. Gamestick isn't even getting enough press to make the radar. Neither of them will get anywhere near the big console makers.
Androids aren't gaming consoles to compete with xbox/ps/nintendo. They're portables that compete with the DS et all. And developers writing Android games are targetting phones and tablets which are 99.9% of the android world, writing games that work with the built in input methods- basically touch screens only. Absolutely nobody is writing Android games assuming you're going to attach a bluetooth gamepad or keyboard.