...I think the defense has the better argument. I have used software tools (both third party and ones I have developed personally) to do source code comparisons and analysis, but they only serve to point me to likely areas of investigation; I have never directly reported and relied upon the output from one of my custom tools in my expert reports.
A key aspect of expert testimony is that your analysis should, in theory, be repeatable by any other qualified expert using the same methodology (which needs to be spelled out in your report). If Perlin is relying directly upon his custom program for his conclusions, he needs to thoroughly expose his methodology -- which, in effect, means either allowing his source code to be reviewed or producing a detailed summary of his methodology that would allow someone else to reproduce it. Trying to claim trade secret status (which is what he's doing, in effect) for a expert methodology is an oxymoron.
In the new NBC series "Heroes Reborn", the big bad corporation, Renautas, is in effect torturing an "evo" (a person with powers) to use her powers to enable a system that can locate all other evos on Earth, so that they can be rounded up. Their corporate motto? "Doing good is good business."
...and while it has significantly better odds than the actual lottery, it's much the same thing. Part of what drives the Valley -- and the IT startup industry in general -- is that it's very easy to track down large numbers of people who have, in fact, become millionaires (or better) through stock options and buy outs. It is a siren song that occasionally pays off.
The problem since the late 1990s is that vast amounts of capital have distorted the natural harsh realities of running a business, not to mention Economics 101. Too many tech startup business plans are, in effect, "Get funding. Create buzz. Get more funding. Sell out to a firm that actually makes money or go public." It occasionally works -- and all you have to do is read the industry press to see the multi-billion-dollar IPOs/acquisitions that never panned out.
Now, excuse me while I go back to work on my indie game and my graphic novel.:-)..bruce..
If I lived in NYC, I would not own a car. We did live in Washington DC (the Very District Itself) for nearly 6 years, but we still needed a car, because it was the only way to go shopping for groceries, etc. Still, while living there, I would regularly go to NYC on business by (a) walking 3 blocks to the Metro station, (b) taking the Metro to Union Station, (c), taking Amtrak to NYC, and (d) walking and/or using taxis in NYC. Coming home, I'd reverse the process.
The fundamental issue with public transit is that unless you have a very dense urban setting, you just can't get around all the places you need to in the time frame required. For vast portions of the US, that just doesn't work all that well.
I didn't know Jobs well, but I did have a number of direct conversations with him, sat in on meetings at NeXT with him, spent five years developing software for NeXTstep, and had many talks with people who worked closely him (again, mostly at NeXT); our last conversation was him calling me up to yell at me for an op-ed piece of mine in BYTE (Nov 94) called "Whither Nextstep?"
With that tee-up, I'll say that Fassbender's portrayal of Jobs in this trailer pretty much falls flat. Fassbender looks too professional and lacks that burning gaze that Jobs used to such great effect, even while using up the people around him. Frankly, Fassbender comes across more like John Scully trying to act like Steve Jobs than like Jobs himself. Also, it took me a bit to realize that Seth Rogan was supposed to be playing Woz; again, the wrong vibes and aura. Frankly, I think that Jack Black with a beard would have been a better choice for Woz...bruce..
/. just ran this article about an Amiga still being used to control HVAC at multiple public schools after nearly 30 years: http://tech.slashdot.org/story...
Technology embeds itself (so to speak); it is far harder to retire old tech (as per this article) than you might think (Windows 8/8.1 just barely passed up WinXP this year). I think that Linux + C makes as much sense as anything, especially for an embedded system, and I'll cheerfully bet that both will still be around and in active use in 25 years...bruce..
3) When a bunch of co-workers start leaving a job or the very best ones in your department start to leave, it's probably time for you to consider leaving too.
It's a good article, but the pattern is an old one. Twenty (20) years ago, I wrote much the same thing about object-oriented technology. Since then, I've found that the same issues, the same pitfalls, pretty much apply to any new technology or methodology; here are some more generalized pitfalls (based on ones from the 1995 book) that I wrote up nearly a decade ago (2008):
-- Adopting a new technology or methodology for the wrong reason -- Thinking a new technology or methodology comes for free -- Thinking a new technology or methodology will solve all your problems -- Betting the company on a given technology or methodology -- Getting religious about the technology or methodology -- Adopting a technology or methodology without well-defined objectives -- Overselling the technology or methodology
These all apply to Agile -- but they also apply to just about every other 'silver bullet' technology or methodology that's come along...bruce..
So, if for example Clinton only dealt with SECRET materials and they were sent or received in her email, all of the equipment (routers, switches, etc.) would have to be rated for that SIPRNet connection. Also, the space in which the equipment and servers and client computers resided in would also have to meet the specifications for SECRET material. This would include various forms of physical access to the space in the form of secure cards, biometrics, etc. No space rated for SECRET opens with a key from the local hardware store. . . .
The biggest issue I see here would be is if the server was connected to the public Internet and it resided in a non-DoD-approved space.
Not sure there are biometrics installed in the Clinton home in Chappaqua...bruce..
My best coding/writing playlist is...the entire set of Moody Blues albums, in chronological order. (I've been listening to them for nearly 50 years. Crap I'm old.) The albums have to play in correct order, and the cuts on each album have to play in standard order. It just pretty much becomes a musical cocoon. I've found that if I'm avoiding doing some necessary writing or coding, I can put the playlist on, and I start working almost immediately.
I do much the same thing with the collected Star Wars soundtracks (played in film sequence, i.e., Eps I through VI; and the soundtracks for the prequels are much better than the movies themselves) and the three LOTR soundtracks (again, played in film sequence).
If I'm getting sleepy, I'll put on "Wireless Barenaked Giants", a playlist containing all my Thomas Dolby, Barenaked Ladies, and TMBG songs, played on shuffle.
Ambient electronic would probably put me to sleep.
I can't thing of a quicker way to terminate an interview with me were I looking to hire developers.
I actually had something a bit like this happen back in 1990 or 1991 when I was building the engineering team for a software startup. I had two developers who were local to the area (San Diego) come in together for interviews. They actually had great resumes and relevant experience -- but when it came to talking compensation, then wanted (a) six-figure salaries (more than I was making as CTO/chief architect), (b) signing bonuses (did I mention that we were a startup and we're still about a year away from closing on venture funding?), and (c) broached the idea of company cars.
I thanked them for coming in and sent them on their way.
The anti-vaxx movement has been almost entirely among liberals and environmentalist, who view Big Pharma and anything "unnatural" with deep suspicion. I've been highly amused at recent efforts to cast it as a conservative cause; there are some anti-vaxxers among the hard right, but the vast majority are on the left.
Having built a long-term development team from scratch, and having screened a lot of consulting software engineers, I eventually came up with an acronym that describes what I look for: Talent, Experience, Professionalism, Education, Skill (TEPES). I wrote a post on the subject back in 2008 -- you can read it here...bruce..
Yep, this is the combo I used. Never had a problem with it. (Actually, had one malware problem before I added Malwarebytes, but used that to remove it and have had it installed ever since.)..bruce..
Seriously, the rush to electronic voting after the 2000 Presidential election was just a bad idea all the way around -- and, frankly, most IT people with any experience were saying so. It is vastly, vastly harder to change physical media than to change electronics.
Eight years ago, Ruby Raley and I published (in Cutter IT Journal) an article entitled "The Longest Yard: Reorganizing IT for Success" (you can read it here). Our basic premise is that the current "industrial" model of IT hiring/management -- treating IT engineers like cogs or components -- is fundamentally flawed, and that a model based on professional sports teams would likely work much better. Having spent 20 years analyzing troubled or failed software projects, I believe we need a significantly different approach on hiring and retaining the right IT engineers...bruce..
I am convinced it's a mistake for this non-profit to create a software development team from a rotating pool of volunteers to write software upon which it is critically dependent.
Yes, it is, for a whole host of reasons that I'm sure will be expanded upon here shortly. I've spent 20 years dealing with troubled and failed IT projects, and one of the biggest mistakes I see time and again is an organization trying to create a mission-critical project, often in a compressed time frame, using developers who are not an experienced, functioning team. You can usually throw into that first-time adoption of some silver-bullet technology and/or methodology. So, what you get it, "OK, let's get 10 random programmers who have never delivered a working system together as a team, and they're going to develop this mission-critical system from scratch in 4 months using Swift and Agile, even though none of the programmers have ever used either. And we can add more programmers if we start to fall behind."
Having the programmers be volunteers is even worse, since they are now self-selecting based on their own interest, instead of being chosen for, you know, actual skills, talent, experience, and so on.
Yep.. Many years ago, I said in testimony before a Congressional committee (yeah, I went there):
"Humanity has been developing information technology for half a century. That experience has taught us this unpleasant truth: virtually every information technology project above a certain size or complexity is significantly late and over budget or fails altogether; those that don't fail are often riddled with defects and difficult to enhance. Fred Brooks explored many of the root causes over twenty years ago in The Mythical Man-Month, a classic book that could be regarded as the Bible of information technology because it is universally known, often quoted, occasionally read, and rarely heeded."
Software is hard, and it gets harder the larger the project. Stupid human behavior just compounds the problem...bruce..
Not to pile on here, but there is nothing new or recent about fear-driven projects of any kind, much less fear-driven IT projects. All you need to do is read some of the classic books on IT project management, including The Psychology of Computer Programming by Jerry Weinberg (1971), The Mythical Man-Month by Fred Brooks (1975), and Death March by Ed Yourdon (1997).
Back in the early 90s, I was chief software architect for a start-up developing a large, complex and novel commercial software product. After working long hours for years, we had missed our original release date and were struggling to come up with a new date that we could be sure of making. Top management (CEO, CFO) was considering carrot/stick "incentives" to "motivate" the engineering team to make a certain date; one of the senior developers stopped me in a hallway by the engineering offices and asked, "Don't they realize they're dealing with grown-ups back here?"
P.S. At the risk of sounding like an old fart, I remain appalled at the profound lack of familiarity among far too many IT industry practitioners of the essential books on software engineering and IT project management. As I have said ad infinitum and ad nauseum, not only do they keep re-inventing the wheel, they keep reinventing the flat tire.
The article was called "The Real Software Crisis" (BYTE, January, 1996); you can read the original text here. (BYTE's archives are no longer online). I wrote a more extended discussion on the subject back in 2008; you can read it here. One might was well write that "normal humans are effectively excluded from composing and performing music"; if you've ever known a music major in college, you'll know just how true that is (I believe Music to be a harder major than Computer Science, having dated a Music major while getting my own degree in CS)...bruce..
SQA as a red-headed stepchild has been an issue for many, many years. It's just that most troubles/failed software systems don't have the widespread public exposure that Healthcare.gov has; even the most brain-dead corporation would not have launched such an incomplete and bug-ridden system to a vast end-user bases.
Some years ago, I led a review of a late (4 yrs vs 2 yrs estimated) and very over-budget ($500M vs. $180M estimated) corporate software project. The core problems had everything to do with SQA, starting with the fact that there was no SQA organization; all testing was done on an ad hoc basis by individual teams and organizations. Adding to that problem was the fact that there was no coherent architecture. After 4 years and $500M, there were no systems that were ready to go into production. Far too common in industry and especially in government...bruce..
Quote 1: "A complex system that works is found to have invariably evolved from a simple system that worked. . ..A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system." (John Gall, Systemantics,p. 80, 1978 paperback edition).
Quote 2: "In architecting a new [software] program all the serious mistakes are made in the first day." (Martin, 1988, cited in Maier & Rechtin, The Art of Systems Architecting (3rd ed.), p. 399)
Quote 3: "Indeed, when asked why so many IT projects go wrong in spite of all we know, one could simply cite the seven deadly sins: avarice, sloth, envy, gluttony, wrath, lust, and pride. It is as good an answer as any and more accurate than most." (me, testifying before the Subcommittee on Government Management, Information, and Technology Hearing, US House of Representatives, June 22, 1998)
My pre- and post-launch analysis of the Healthcare.gov website can be found here...bruce..
Slashdot Mirror
...I think the defense has the better argument. I have used software tools (both third party and ones I have developed personally) to do source code comparisons and analysis, but they only serve to point me to likely areas of investigation; I have never directly reported and relied upon the output from one of my custom tools in my expert reports.
A key aspect of expert testimony is that your analysis should, in theory, be repeatable by any other qualified expert using the same methodology (which needs to be spelled out in your report). If Perlin is relying directly upon his custom program for his conclusions, he needs to thoroughly expose his methodology -- which, in effect, means either allowing his source code to be reviewed or producing a detailed summary of his methodology that would allow someone else to reproduce it. Trying to claim trade secret status (which is what he's doing, in effect) for a expert methodology is an oxymoron.
In the new NBC series "Heroes Reborn", the big bad corporation, Renautas, is in effect torturing an "evo" (a person with powers) to use her powers to enable a system that can locate all other evos on Earth, so that they can be rounded up. Their corporate motto? "Doing good is good business."
There you go.
...and while it has significantly better odds than the actual lottery, it's much the same thing. Part of what drives the Valley -- and the IT startup industry in general -- is that it's very easy to track down large numbers of people who have, in fact, become millionaires (or better) through stock options and buy outs. It is a siren song that occasionally pays off.
The problem since the late 1990s is that vast amounts of capital have distorted the natural harsh realities of running a business, not to mention Economics 101. Too many tech startup business plans are, in effect, "Get funding. Create buzz. Get more funding. Sell out to a firm that actually makes money or go public." It occasionally works -- and all you have to do is read the industry press to see the multi-billion-dollar IPOs/acquisitions that never panned out.
Now, excuse me while I go back to work on my indie game and my graphic novel. :-) ..bruce..
If I lived in NYC, I would not own a car. We did live in Washington DC (the Very District Itself) for nearly 6 years, but we still needed a car, because it was the only way to go shopping for groceries, etc. Still, while living there, I would regularly go to NYC on business by (a) walking 3 blocks to the Metro station, (b) taking the Metro to Union Station, (c), taking Amtrak to NYC, and (d) walking and/or using taxis in NYC. Coming home, I'd reverse the process.
The fundamental issue with public transit is that unless you have a very dense urban setting, you just can't get around all the places you need to in the time frame required. For vast portions of the US, that just doesn't work all that well.
I didn't know Jobs well, but I did have a number of direct conversations with him, sat in on meetings at NeXT with him, spent five years developing software for NeXTstep, and had many talks with people who worked closely him (again, mostly at NeXT); our last conversation was him calling me up to yell at me for an op-ed piece of mine in BYTE (Nov 94) called "Whither Nextstep?"
With that tee-up, I'll say that Fassbender's portrayal of Jobs in this trailer pretty much falls flat. Fassbender looks too professional and lacks that burning gaze that Jobs used to such great effect, even while using up the people around him. Frankly, Fassbender comes across more like John Scully trying to act like Steve Jobs than like Jobs himself. Also, it took me a bit to realize that Seth Rogan was supposed to be playing Woz; again, the wrong vibes and aura. Frankly, I think that Jack Black with a beard would have been a better choice for Woz. ..bruce..
/. just ran this article about an Amiga still being used to control HVAC at multiple public schools after nearly 30 years: http://tech.slashdot.org/story...
Technology embeds itself (so to speak); it is far harder to retire old tech (as per this article) than you might think (Windows 8/8.1 just barely passed up WinXP this year). I think that Linux + C makes as much sense as anything, especially for an embedded system, and I'll cheerfully bet that both will still be around and in active use in 25 years. ..bruce..
Hence, the Dead Sea Effect". ..bruce..
It's a good article, but the pattern is an old one. Twenty (20) years ago, I wrote much the same thing about object-oriented technology. Since then, I've found that the same issues, the same pitfalls, pretty much apply to any new technology or methodology; here are some more generalized pitfalls (based on ones from the 1995 book) that I wrote up nearly a decade ago (2008):
-- Adopting a new technology or methodology for the wrong reason
-- Thinking a new technology or methodology comes for free
-- Thinking a new technology or methodology will solve all your problems
-- Betting the company on a given technology or methodology
-- Getting religious about the technology or methodology
-- Adopting a technology or methodology without well-defined objectives
-- Overselling the technology or methodology
These all apply to Agile -- but they also apply to just about every other 'silver bullet' technology or methodology that's come along. ..bruce..
I had someone who did SECRET-grade e-mails setup in the military write the following to me:
Not sure there are biometrics installed in the Clinton home in Chappaqua. ..bruce..
My best coding/writing playlist is...the entire set of Moody Blues albums, in chronological order. (I've been listening to them for nearly 50 years. Crap I'm old.) The albums have to play in correct order, and the cuts on each album have to play in standard order. It just pretty much becomes a musical cocoon. I've found that if I'm avoiding doing some necessary writing or coding, I can put the playlist on, and I start working almost immediately.
I do much the same thing with the collected Star Wars soundtracks (played in film sequence, i.e., Eps I through VI; and the soundtracks for the prequels are much better than the movies themselves) and the three LOTR soundtracks (again, played in film sequence).
If I'm getting sleepy, I'll put on "Wireless Barenaked Giants", a playlist containing all my Thomas Dolby, Barenaked Ladies, and TMBG songs, played on shuffle.
Ambient electronic would probably put me to sleep.
I can't thing of a quicker way to terminate an interview with me were I looking to hire developers.
I actually had something a bit like this happen back in 1990 or 1991 when I was building the engineering team for a software startup. I had two developers who were local to the area (San Diego) come in together for interviews. They actually had great resumes and relevant experience -- but when it came to talking compensation, then wanted (a) six-figure salaries (more than I was making as CTO/chief architect), (b) signing bonuses (did I mention that we were a startup and we're still about a year away from closing on venture funding?), and (c) broached the idea of company cars.
I thanked them for coming in and sent them on their way.
The anti-vaxx movement has been almost entirely among liberals and environmentalist, who view Big Pharma and anything "unnatural" with deep suspicion. I've been highly amused at recent efforts to cast it as a conservative cause; there are some anti-vaxxers among the hard right, but the vast majority are on the left.
Having built a long-term development team from scratch, and having screened a lot of consulting software engineers, I eventually came up with an acronym that describes what I look for: Talent, Experience, Professionalism, Education, Skill (TEPES). I wrote a post on the subject back in 2008 -- you can read it here. ..bruce..
Yep, this is the combo I used. Never had a problem with it. (Actually, had one malware problem before I added Malwarebytes, but used that to remove it and have had it installed ever since.) ..bruce..
Seriously, the rush to electronic voting after the 2000 Presidential election was just a bad idea all the way around -- and, frankly, most IT people with any experience were saying so. It is vastly, vastly harder to change physical media than to change electronics.
Eight years ago, Ruby Raley and I published (in Cutter IT Journal) an article entitled "The Longest Yard: Reorganizing IT for Success" (you can read it here). Our basic premise is that the current "industrial" model of IT hiring/management -- treating IT engineers like cogs or components -- is fundamentally flawed, and that a model based on professional sports teams would likely work much better. Having spent 20 years analyzing troubled or failed software projects, I believe we need a significantly different approach on hiring and retaining the right IT engineers. ..bruce..
Yes, it is, for a whole host of reasons that I'm sure will be expanded upon here shortly. I've spent 20 years dealing with troubled and failed IT projects, and one of the biggest mistakes I see time and again is an organization trying to create a mission-critical project, often in a compressed time frame, using developers who are not an experienced, functioning team. You can usually throw into that first-time adoption of some silver-bullet technology and/or methodology. So, what you get it, "OK, let's get 10 random programmers who have never delivered a working system together as a team, and they're going to develop this mission-critical system from scratch in 4 months using Swift and Agile, even though none of the programmers have ever used either. And we can add more programmers if we start to fall behind."
Having the programmers be volunteers is even worse, since they are now self-selecting based on their own interest, instead of being chosen for, you know, actual skills, talent, experience, and so on.
Sigh. ..bruce..
Yep.. Many years ago, I said in testimony before a Congressional committee (yeah, I went there):
Software is hard, and it gets harder the larger the project. Stupid human behavior just compounds the problem. ..bruce..
Not to pile on here, but there is nothing new or recent about fear-driven projects of any kind, much less fear-driven IT projects. All you need to do is read some of the classic books on IT project management, including The Psychology of Computer Programming by Jerry Weinberg (1971), The Mythical Man-Month by Fred Brooks (1975), and Death March by Ed Yourdon (1997).
Back in the early 90s, I was chief software architect for a start-up developing a large, complex and novel commercial software product. After working long hours for years, we had missed our original release date and were struggling to come up with a new date that we could be sure of making. Top management (CEO, CFO) was considering carrot/stick "incentives" to "motivate" the engineering team to make a certain date; one of the senior developers stopped me in a hallway by the engineering offices and asked, "Don't they realize they're dealing with grown-ups back here?"
P.S. At the risk of sounding like an old fart, I remain appalled at the profound lack of familiarity among far too many IT industry practitioners of the essential books on software engineering and IT project management. As I have said ad infinitum and ad nauseum, not only do they keep re-inventing the wheel, they keep reinventing the flat tire.
The article was called "The Real Software Crisis" (BYTE, January, 1996); you can read the original text here. (BYTE's archives are no longer online). I wrote a more extended discussion on the subject back in 2008; you can read it here. One might was well write that "normal humans are effectively excluded from composing and performing music"; if you've ever known a music major in college, you'll know just how true that is (I believe Music to be a harder major than Computer Science, having dated a Music major while getting my own degree in CS). ..bruce..
SQA as a red-headed stepchild has been an issue for many, many years. It's just that most troubles/failed software systems don't have the widespread public exposure that Healthcare.gov has; even the most brain-dead corporation would not have launched such an incomplete and bug-ridden system to a vast end-user bases.
Some years ago, I led a review of a late (4 yrs vs 2 yrs estimated) and very over-budget ($500M vs. $180M estimated) corporate software project. The core problems had everything to do with SQA, starting with the fact that there was no SQA organization; all testing was done on an ad hoc basis by individual teams and organizations. Adding to that problem was the fact that there was no coherent architecture. After 4 years and $500M, there were no systems that were ready to go into production. Far too common in industry and especially in government. ..bruce..
Quote 1: "A complex system that works is found to have invariably evolved from a simple system that worked. . . .A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system." (John Gall, Systemantics,p. 80, 1978 paperback edition).
Quote 2: "In architecting a new [software] program all the serious mistakes are made in the first day." (Martin, 1988, cited in Maier & Rechtin, The Art of Systems Architecting (3rd ed.), p. 399)
Quote 3: "Indeed, when asked why so many IT projects go wrong in spite of all we know, one could simply cite the seven deadly sins: avarice, sloth, envy, gluttony, wrath, lust, and pride. It is as good an answer as any and more accurate than most." (me, testifying before the Subcommittee on Government Management, Information, and Technology Hearing, US House of Representatives, June 22, 1998)
My pre- and post-launch analysis of the Healthcare.gov website can be found here. ..bruce..
..but also Brooks's Law:
"Adding manpower to a late project makes it later." ..bruce..
I think MS is seriously underestimating the reluctance of its base to move off Win7 to Win8 (or even 8.1).