A vendor will sell you, or often give you a free trial of, their vulnerability scanning tool. They will then turn right around and sell you a tool that is supposed to fix those problems. Does anyone else see a problem with that? One reason I prefer the FOSS tools going back to Nmap and SATAN is that they do what real intruders try to do, not what some marketing department wants them to do as a way to scare you into buying stuff.
From the headline, I was expecting a story about the code for the iPhone being put under the microscope of a top-to-bottom review -- you know, "The Code Review of Doom".
Spoiled and demanding instant gratification they may be, but the management at their corporate overlords will just LOVE them, especially if they go into IT. No more of the grousing our generation does about being on 15-minute response call 24/7/365! Their managers will exploit this to make them feel guilty about taking more than 5 minutes to get to fixing something.
Conspiracy theory much? Claiming the game is 'rigged' because there are little or no published research supporting the denialists is, at best, disingenuous. Where is the support for this claim that alternative views are suppressed? Please cite something other than a blogger.
Where is their peer-reviewed paper in a respected journal? Is that too "sciencey"? Why do people with no credentials insist that their claims merit as much attention as carefully researched and reviewed investigations?
That's been my experience. They offer promotions up to line management (the lowest level) of people they want to keep, then move to a contract/outsource/offshore model and let the rest go. The 24/7 including holidays on call requirement sounds like something a company would do when they are expecting to have a lot of folk in India doing the technical work.
If that's the company's direction, then I would expect the OP to be let go at some point if he doesn't take the promotion. The company is expecting to be able to replace his technical role with someone cheaper.
Facebook Inc. converted its existing stock holdings into different classes of stocks (Class A and Class B) designed to give certain shareholders more power than others.
Translation: a few people well-connected with the founders and some VCs will make off with most of what money there is now, while the getting is good. Everyone else, like the employees that were enticed to go to work for FB with promises of "valuable stock options", will get diddly squat.
Facebook might not even IPO, they might sell out to someone like Rupert Murdoch, with the people holding the better class of stock getting a hefty payday, while everyone else will just get a handful oh-so-valuable shares of News Corp thrown at them.
My "why" was really more of a rhetorical question. In my experience, setting up and maintaining an automated build/test/deploy for a complex thing like IE is quite a lot of work, and I'm not sure any team would benefit from the effort if the only benefit was just keep the build from breaking. That could be done by having a designated team member manually build the system whenever there was time (hah) and a need to check it. No, to make a frequent build worth the effort, you need to get the resulting software in front of real users who can give feedback.
How's that constantly changing never quite know what you're building agile shitfight working for you?
It works quite well, actually, when you have frequent releases to the user, because they can say "yes this is good" or "no this isn't good", and only OCD types really worry about knowing exactly what's what at any time. In fact, software projects tend to delude themselves into thinking they know what they've got when they really don't. This leads to all kinds of problems later when the users see it and find out that what they got is nothing like what they were told they were going to get.
Think of it this way -- you're crossing a swift-flowing river in the middle of a black night on a small boat. Would you rather do it the waterfall way: shine a bright light at the dock on the opposite bank before you start, then turn it off and start rowing towards where you shone the line and expect to get there, or agile way: carry a light with you and alternate rowing and shining it across the river to see which way that dock is?
A monolithic blob of pieces that have tight coupling between each other and leak those dependencies to other pieces that shouldn't even KNOW about another applications dependencies in the first place is bad software engineering. Again, the article is correct in urging the frequent build/test/release to the public cycle because it would highlight the dependency errors quickly and allow them to be fixed before they become a problem. We all know DLL hell (or RPM hell -- linux doesn't get a pass here, either) and the way out is to discover the dependencies early and break them soon.
It's not that MS shouldn't do it because they have tight couplings in IE, it's that the IE team NEEDS to do it to identify and fix the tight coupling problems. That's basic stuff in correct software engineering.
You're right, we don't know what the IE development team has or doesn't have. Still, what's the point of going to all the trouble to create a good automated build/test/release system and not have frequent deliveries to the end users - the web development community in this case? I've seen teams do that, and over the life of the project it felt like a net loss because the time and effort spent babysitting the build was wasted because break in the feedback loop by not getting it to end users meant that what was worked on didn't adequately track the real needs. Sure, the developers were able to get immediate information on the health of the system, but it didn't provide them with any information about the correctness.
The IE guys are going to have to fix any problems in how it plays nice with Windows anyway, and if the development process is so broken that they can't even keep O/S-breaking regressions out of the builds, there's a problem. The whole point of having frequent builds is to identify errors sooner, while it's cheaper and easier to fix them, than later, after the edifice has been built on the unstable foundation.
with Firefox if you file a bug they appreciate that and generally fix it right away, even security vulnerabilities aren't promptly fixed on IE, let alone user suggestions....
I suggest that's the whole point of wanting IE to have a more frequent build and release cycle -- getting rapid and frequent feedback along with frequent builds enables rapid fixes.
'if Trident breaks, a lot of other stuff in Windows breaks'
Which is, of course, precisely the reason to have a meaningful suite of automated tests and frequent build/test cycles. You'd rather work 6 months on something and then throw it over the wall to testers only to have them come back with either hundreds of regression failures (best case) or a handful of failures so severe they couldn't even get past the basic smoke test script?
That's even before you get to your user community, which as the article points out happened with IE8, when the beta is sprung on the web development world with catastrophic amounts of breakage of existing pages?
Sorry, but taking an existing invention and just taking on "in Excel" or "using a computer" does not make it a new invention. That seems to be the way the USPTO treats those magic words, though.
You can buy a lot of marketshare with as much cash as Microsoft has. Paying Verizon, e.g. to use Bing as the default search engine on their smart phones gets a lot of market share without having to actually bring user choice into the mix.
Slashdot Mirror
This is why I shoot film on an old manual camera.
TL;DR
Also -- PowerPoint graphics ftl.
So, Lua, hmm. Maybe all those hours I spent writing addons for World of Warcraft weren't entirely wasted. Just mostly.
A vendor will sell you, or often give you a free trial of, their vulnerability scanning tool. They will then turn right around and sell you a tool that is supposed to fix those problems. Does anyone else see a problem with that? One reason I prefer the FOSS tools going back to Nmap and SATAN is that they do what real intruders try to do, not what some marketing department wants them to do as a way to scare you into buying stuff.
From the headline, I was expecting a story about the code for the iPhone being put under the microscope of a top-to-bottom review -- you know, "The Code Review of Doom".
That's OK, they'll get their comeuppance when they go into the workforce and find management also expects instantaneous access to them -- 24/7/365.
Spoiled and demanding instant gratification they may be, but the management at their corporate overlords will just LOVE them, especially if they go into IT. No more of the grousing our generation does about being on 15-minute response call 24/7/365! Their managers will exploit this to make them feel guilty about taking more than 5 minutes to get to fixing something.
Given the credentials of the original press release (really that's all it was), my response was more scientific than the denialist's article.
Conspiracy theory much? Claiming the game is 'rigged' because there are little or no published research supporting the denialists is, at best, disingenuous. Where is the support for this claim that alternative views are suppressed? Please cite something other than a blogger.
Where is their peer-reviewed paper in a respected journal? Is that too "sciencey"? Why do people with no credentials insist that their claims merit as much attention as carefully researched and reviewed investigations?
That's been my experience. They offer promotions up to line management (the lowest level) of people they want to keep, then move to a contract/outsource/offshore model and let the rest go. The 24/7 including holidays on call requirement sounds like something a company would do when they are expecting to have a lot of folk in India doing the technical work.
If that's the company's direction, then I would expect the OP to be let go at some point if he doesn't take the promotion. The company is expecting to be able to replace his technical role with someone cheaper.
Somalia: libertarian paradise!
Facebook Inc. converted its existing stock holdings into different classes of stocks (Class A and Class B) designed to give certain shareholders more power than others.
Translation: a few people well-connected with the founders and some VCs will make off with most of what money there is now, while the getting is good. Everyone else, like the employees that were enticed to go to work for FB with promises of "valuable stock options", will get diddly squat.
Facebook might not even IPO, they might sell out to someone like Rupert Murdoch, with the people holding the better class of stock getting a hefty payday, while everyone else will just get a handful oh-so-valuable shares of News Corp thrown at them.
My "why" was really more of a rhetorical question. In my experience, setting up and maintaining an automated build/test/deploy for a complex thing like IE is quite a lot of work, and I'm not sure any team would benefit from the effort if the only benefit was just keep the build from breaking. That could be done by having a designated team member manually build the system whenever there was time (hah) and a need to check it. No, to make a frequent build worth the effort, you need to get the resulting software in front of real users who can give feedback.
How's that constantly changing never quite know what you're building agile shitfight working for you?
It works quite well, actually, when you have frequent releases to the user, because they can say "yes this is good" or "no this isn't good", and only OCD types really worry about knowing exactly what's what at any time. In fact, software projects tend to delude themselves into thinking they know what they've got when they really don't. This leads to all kinds of problems later when the users see it and find out that what they got is nothing like what they were told they were going to get.
Think of it this way -- you're crossing a swift-flowing river in the middle of a black night on a small boat. Would you rather do it the waterfall way: shine a bright light at the dock on the opposite bank before you start, then turn it off and start rowing towards where you shone the line and expect to get there, or agile way: carry a light with you and alternate rowing and shining it across the river to see which way that dock is?
A monolithic blob of pieces that have tight coupling between each other and leak those dependencies to other pieces that shouldn't even KNOW about another applications dependencies in the first place is bad software engineering. Again, the article is correct in urging the frequent build/test/release to the public cycle because it would highlight the dependency errors quickly and allow them to be fixed before they become a problem. We all know DLL hell (or RPM hell -- linux doesn't get a pass here, either) and the way out is to discover the dependencies early and break them soon.
It's not that MS shouldn't do it because they have tight couplings in IE, it's that the IE team NEEDS to do it to identify and fix the tight coupling problems. That's basic stuff in correct software engineering.
Which ones can you show are valid and have not been addressed by agile?
You're right, we don't know what the IE development team has or doesn't have. Still, what's the point of going to all the trouble to create a good automated build/test/release system and not have frequent deliveries to the end users - the web development community in this case? I've seen teams do that, and over the life of the project it felt like a net loss because the time and effort spent babysitting the build was wasted because break in the feedback loop by not getting it to end users meant that what was worked on didn't adequately track the real needs. Sure, the developers were able to get immediate information on the health of the system, but it didn't provide them with any information about the correctness.
Wow, you can't come up with anything newer than a link to Yegge's tired old disproven rant?
The IE guys are going to have to fix any problems in how it plays nice with Windows anyway, and if the development process is so broken that they can't even keep O/S-breaking regressions out of the builds, there's a problem. The whole point of having frequent builds is to identify errors sooner, while it's cheaper and easier to fix them, than later, after the edifice has been built on the unstable foundation.
with Firefox if you file a bug they appreciate that and generally fix it right away, even security vulnerabilities aren't promptly fixed on IE, let alone user suggestions....
I suggest that's the whole point of wanting IE to have a more frequent build and release cycle -- getting rapid and frequent feedback along with frequent builds enables rapid fixes.
'if Trident breaks, a lot of other stuff in Windows breaks'
Which is, of course, precisely the reason to have a meaningful suite of automated tests and frequent build/test cycles. You'd rather work 6 months on something and then throw it over the wall to testers only to have them come back with either hundreds of regression failures (best case) or a handful of failures so severe they couldn't even get past the basic smoke test script?
That's even before you get to your user community, which as the article points out happened with IE8, when the beta is sprung on the web development world with catastrophic amounts of breakage of existing pages?
How's that non-agile, waterfall QA working out for ya?
Sorry, but taking an existing invention and just taking on "in Excel" or "using a computer" does not make it a new invention. That seems to be the way the USPTO treats those magic words, though.
You can buy a lot of marketshare with as much cash as Microsoft has. Paying Verizon, e.g. to use Bing as the default search engine on their smart phones gets a lot of market share without having to actually bring user choice into the mix.
s/Maintenance/Development/
Oh sure, there are a handful who know something, but to a first approximation, the above is correct.