No matter how long or short they are, standups are worthless (except, I suppose, if the team is dysfunctional to begin with). In a well functioning team, everything that is supposed to be accomplished in a standup is accomplished in real-time as it happens. So there's nothing new to be said in the stand up.
In my experience, that would be greatly preferable to Agile.
But Agile works better than any other methodology that I have used, even when implemented piecemeal, by mediocre programmers, rather than in its "ideal form".
My experience is just the opposite: agile is very nearly the worst of the methodologies I've used. The one great thing about it is something that can be done in any methodology: increased communications. We can throw out the bathwater and keep that baby.
Agile started failing pretty much as soon as it met the real world. I disagree with Andy Hunt's explanation of why, though. It's not because "thinking is hard", it's mostly because of two things: management not allowing agile to be done correctly, and (from the developer's point of view) it drains software engineering of the things that make it a satisfying and enjoyable activity, turning it into the software equivalent of grunt factory work.
End the antiquated requirement for anonymous ballots
There's nothing antiquated about anonymous ballots. Voting secrecy is as critical now as it has ever been, for all of the same reasons: to minimize reprisals from friends, family, employers, and the government for voting "the wrong way", and to decrease the ease with which people can be coerced or bribed to vote a particular way (since the ones doing the bribing or coercing can't verify that you voted the way they want.)
Me either. But those privacy concerns you mention are such a huge deal that I try very hard to never send email to a gmail address. And when I have to send email to one, I say as little as I can possibly get away with.
What about all the people that can ONLY get AOL in their rural areas (the Comcast "go fuck yourself" zones)?
I don't believe there exists any place in the nation where your only choice for internet service is AOL. There are many other dialup providers that are a local phone call from pretty much everywhere.
"Yes, but back in 1993 its not like you could just Google it."
No, but you could find local ISPs in the phone book. AOL has always been for two kinds of people: those who live someplace that had no ISPs, and those who wanted their hands to be held when they were doing that scary "online" thing.
It's the latter group that leads to aol.com email addresses being an indicator of someone who is clueless. Those people who started on AOL and actually learned stuff soon migrated to something better than AOL.
As others have said, by the people who wrote the language. And by the entire software industry as well. I was honestly surprised that anyone characterized C as a high level language. It's not just wrong (by the usual definitions of what low, mid, or high-level means) but is not the common understanding in the industry.
How many ways are there to dereference a pointer? you can use either *foo or foo[0] but why? Nothing is gained from having two ways to do it, it just makes the language more obscure.
Something is gained, though: self-documentation. The way you dereference a point (should) reflect what the pointer is being used for.
And when C was developed, it was a HIGH-LEVEL language.
Umm, no, it wasn't. It was (and is) considered a mid-level language, one step above assembler. High level languages of the day were things like COBOL and Fortran.
Just to be clear, I didn't say there were things that couldn't be done through web interfaces, just that they apparently can't be done nearly as well. This is entirely based on my experiences with both web-based and native application UIs. In the best web-based UIs I've seen, the problem is usually that they're annoyingly slow and/or laggy. Most web-based UIs have additional issues on top of that (formatting problems, etc.) All web-based UIs share other really annoying problems, like when transient network errors happen right after you push a button or enter some text.
They all also have the problem that they have to operate within a browser window, which severely constrains UI design.
While it was all you had back in the days of 486's and Pentiums, the entire industry has evolved.
Since the cloud is nothing more than a return to the bad old days of client/server computing, I think that this is more properly stated as "the entire industry has devolved".
With FTL, JavaScriptCore can run C code compiled via Emscriptem to JavaScript at around 60% of the speed of the same C code compiled directly. That's not a huge overhead (40% is a generation old CPU, or a C compiler from 5 years earlier).
I strongly disagree. 40% is an absolutely horrendous amount of overhead. Comparing that loss to old CPUs and the like to argue that it's not doesn't make any sense at all.
I suspect many "desktop" software companies will hedge and build the app as a web app, BUT keep a "local virtual web server" option so that it can have quick access to local disk etc. if needed.
But that wouldn't solve the problem of having to use a web-based UI.
but I DO blame us, the consumers, for falling for every god damned privacy-invading scheme conceivable.
I blame both. This is such an obviously terrible idea that I blame Apple for not killing it as soon as the first person uttered it in the meeting. It shows a reckless disregard for their customers.
Sure, until insurance companies and governments start demanding access to it.
That's certainly something worth worrying about (it would really piss me off, that's for sure), but how does this make it significantly more likely?
Because it is creating what amounts to a massive DNA database. Once that is done, it is essentially inevitable that the data will be sued by insurance companies, governments, advertising agencies, hackers, and other ne'er-do-wells. This is a disaster in the making.
I believe this is a move in the right direction and can only help people be more secure, not less.
I'm very much in favor of end-to-end encryption of all things. That said, I think this is a seriously bad move on the part of Mozilla.
There's a pretty huge difference between helping people to be more secure and forcing people to be more secure. Mozilla is forcing people. This is Mozilla attacking people so they'll do what Mozilla has deemed to be The Right Thing. That it is indeed The Right Thing in no way excuses using the tactic of force.
But now if they block Firefox the reason will be widely known and the bank subject to public ridicule.
Haha haha. Most people won't understand why, and most people won't care.
And then there will be people like me: who understand why, and still don't care. If Firefox stops working with web sites I need to go to, I'll just stop using Firefox. I'm already a long way there: there is an increasing number of websites that Firefox doesn't work well with, and so I have to use a different browser for them.
Slashdot Mirror
No matter how long or short they are, standups are worthless (except, I suppose, if the team is dysfunctional to begin with). In a well functioning team, everything that is supposed to be accomplished in a standup is accomplished in real-time as it happens. So there's nothing new to be said in the stand up.
Are we going to go back to Waterfall?
In my experience, that would be greatly preferable to Agile.
But Agile works better than any other methodology that I have used, even when implemented piecemeal, by mediocre programmers, rather than in its "ideal form".
My experience is just the opposite: agile is very nearly the worst of the methodologies I've used. The one great thing about it is something that can be done in any methodology: increased communications. We can throw out the bathwater and keep that baby.
Agile started failing pretty much as soon as it met the real world. I disagree with Andy Hunt's explanation of why, though. It's not because "thinking is hard", it's mostly because of two things: management not allowing agile to be done correctly, and (from the developer's point of view) it drains software engineering of the things that make it a satisfying and enjoyable activity, turning it into the software equivalent of grunt factory work.
End the antiquated requirement for anonymous ballots
There's nothing antiquated about anonymous ballots. Voting secrecy is as critical now as it has ever been, for all of the same reasons: to minimize reprisals from friends, family, employers, and the government for voting "the wrong way", and to decrease the ease with which people can be coerced or bribed to vote a particular way (since the ones doing the bribing or coercing can't verify that you voted the way they want.)
So I don't judge GMAIL users to harshly
Me either. But those privacy concerns you mention are such a huge deal that I try very hard to never send email to a gmail address. And when I have to send email to one, I say as little as I can possibly get away with.
What about all the people that can ONLY get AOL in their rural areas (the Comcast "go fuck yourself" zones)?
I don't believe there exists any place in the nation where your only choice for internet service is AOL. There are many other dialup providers that are a local phone call from pretty much everywhere.
Broadband isn't available in most of the city so I still run into a lot of people that still use @aol.com email addresses.
The lack of broadband doesn't explain the use of AOL at all. Why aren't people using a better ISP?
"Yes, but back in 1993 its not like you could just Google it."
No, but you could find local ISPs in the phone book. AOL has always been for two kinds of people: those who live someplace that had no ISPs, and those who wanted their hands to be held when they were doing that scary "online" thing.
It's the latter group that leads to aol.com email addresses being an indicator of someone who is clueless. Those people who started on AOL and actually learned stuff soon migrated to something better than AOL.
Of course it does. Is this even a question worth asking?
By who?
As others have said, by the people who wrote the language. And by the entire software industry as well. I was honestly surprised that anyone characterized C as a high level language. It's not just wrong (by the usual definitions of what low, mid, or high-level means) but is not the common understanding in the industry.
C++ is a high-level language, though.
How many ways are there to dereference a pointer? you can use either *foo or foo[0] but why? Nothing is gained from having two ways to do it, it just makes the language more obscure.
Something is gained, though: self-documentation. The way you dereference a point (should) reflect what the pointer is being used for.
Nobody uses C or C++ because they love the language.
I do. I routinely use about a dozen different languages, but C++ remains my favorite by a longshot, followed closely by C.
And when C was developed, it was a HIGH-LEVEL language.
Umm, no, it wasn't. It was (and is) considered a mid-level language, one step above assembler. High level languages of the day were things like COBOL and Fortran.
Just to be clear, I didn't say there were things that couldn't be done through web interfaces, just that they apparently can't be done nearly as well. This is entirely based on my experiences with both web-based and native application UIs. In the best web-based UIs I've seen, the problem is usually that they're annoyingly slow and/or laggy. Most web-based UIs have additional issues on top of that (formatting problems, etc.) All web-based UIs share other really annoying problems, like when transient network errors happen right after you push a button or enter some text.
They all also have the problem that they have to operate within a browser window, which severely constrains UI design.
While it was all you had back in the days of 486's and Pentiums, the entire industry has evolved.
Since the cloud is nothing more than a return to the bad old days of client/server computing, I think that this is more properly stated as "the entire industry has devolved".
With FTL, JavaScriptCore can run C code compiled via Emscriptem to JavaScript at around 60% of the speed of the same C code compiled directly. That's not a huge overhead (40% is a generation old CPU, or a C compiler from 5 years earlier).
I strongly disagree. 40% is an absolutely horrendous amount of overhead. Comparing that loss to old CPUs and the like to argue that it's not doesn't make any sense at all.
I suspect many "desktop" software companies will hedge and build the app as a web app, BUT keep a "local virtual web server" option so that it can have quick access to local disk etc. if needed.
But that wouldn't solve the problem of having to use a web-based UI.
Right now the limits are in High End Graphic Processing, and Interfacing with external hardware.
And user interface in general. I've yet to see a web-based UI that even comes close to being as good as a well-developed native one.
Everyone thinks the cloud is great
Not everyone. I, for one, think that the cloud is the exact opposite of great. No third party provider can be trusted, by law.
Very unlikely. HIPAA only applies to specific entities. Apple is not one of those entities.
I don't blame apple for wanting to do this.
but I DO blame us, the consumers, for falling for every god damned privacy-invading scheme conceivable.
I blame both. This is such an obviously terrible idea that I blame Apple for not killing it as soon as the first person uttered it in the meeting. It shows a reckless disregard for their customers.
Sure, until insurance companies and governments start demanding access to it.
That's certainly something worth worrying about (it would really piss me off, that's for sure), but how does this make it significantly more likely?
Because it is creating what amounts to a massive DNA database. Once that is done, it is essentially inevitable that the data will be sued by insurance companies, governments, advertising agencies, hackers, and other ne'er-do-wells. This is a disaster in the making.
That's OK. I already avoid Chrome to the greatest extent that I can.
I believe this is a move in the right direction and can only help people be more secure, not less.
I'm very much in favor of end-to-end encryption of all things. That said, I think this is a seriously bad move on the part of Mozilla.
There's a pretty huge difference between helping people to be more secure and forcing people to be more secure. Mozilla is forcing people. This is Mozilla attacking people so they'll do what Mozilla has deemed to be The Right Thing. That it is indeed The Right Thing in no way excuses using the tactic of force.
But now if they block Firefox the reason will be widely known and the bank subject to public ridicule.
Haha haha. Most people won't understand why, and most people won't care.
And then there will be people like me: who understand why, and still don't care. If Firefox stops working with web sites I need to go to, I'll just stop using Firefox. I'm already a long way there: there is an increasing number of websites that Firefox doesn't work well with, and so I have to use a different browser for them.
Yes, the browser wars are on their way back.