The bit about relationships not scaling is well documented. The studies most interesting to me are the ones that suggest it is an evolved limit. If you'd like a general introduction, pretty much any introductory cultural anthropology text would cover that. Or you could dive right in with Co-evolution of Neocortex Size, Group Size, and Language in Humans and the references from there.
Software companies often need to create large, new features, and don't wish to destabilize the core product.
Solution: stop checking in stuff that doesn't work. I do this through unit testing, acceptance testing, pair programming, working within a few paces of a product manager, and a few other practices.
Or it's because it's *far* easier for developers to be able to branch pieces of code, work on feature or bugfix development in their own little playpen.
I don't have anything against local copies. It's kinda hard to change the code if you can't change the code.
being able to revert a messed up piece of code is awfully handy
True. I use an IDE with undo for small cases of this, and reversion to head for large versions. But I think a better solution is to find mistakes early, so that screwing up is easy to fix.
This also facilitates easier code review
This is true only if you're willing to pay the cost of slower code review. Longer feedback loops inevitably create greater waste than shorter ones.
Or because, in a more contract-oriented world, they might need to build customized applications for customers, and branch-and-merge strategies make that kind of code management possible.
I have never seen that not be the road to maintenance hell. For the customized versions of products I've worked on, it's not like customers don't want all the bug fixes and new features that you're putting into the app. They do, just with their customizations. Trying to juggle all that through branching and merging seems like a lot more work than just making the software configurable, templatable, or customizable directly.
Honestly, if you've never seen the need to branch-and-merge, you've never worked on a large project. Period.
I don't remember saying I've never seen the need for that. Perhaps you replied to the wrong post?
That may work fine when you're the only one working on the code, but if you're working with someone else, and he's committed code that you don't think is any good (or at least not ready for production yet), but later commits from you are, then with a single trunk you're simply out of luck.
This is back to my original point. If I'm working with people who are regularly checking in bad code, then I solve that by talking with the person. Why would I let him go on doing dumb things any longer than necessary?
But what if you've been working on something that seemed like a good idea at the time, and suddenly you realise you're going completely in the wrong direction and need to undo a lot of commits (but you want to keep the other bugfixes you did)? Or what if someone else is working on the same project?
I mainly solve this by making sure it doesn't happen much. Branching can only save you if you realize it's a bad idea before you merge to trunk, only if your changes are mostly bad. I think the solution to bad ideas is better product management, not better version control.
Have you read what you just wrote here? Ofcourse the point of branching is not to increase complexity. It's to reduce it.
Let's take a simple example. Me and my team are developing against trunk, committing every few hours, and shipping weekly. How many relevant versions of the software are there?
I count 2. One's in production, and one's at the head of the trunk. The divergence between the two is at maximum, however much the team can develop in a week.
Now I branch. How many interesting versions are there? I count 3. How much divergence is there? Well, there's release to head, release to branch, and branch to head.
So that's 2 versions with 1 axis of divergence, versus 3 versions with 3 axes of divergence.
No matter how you measure it, that is increased complexity.
Easily, the most common reason for branching is a stable-versus-development split.
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
I've run into that a million times with copy changes. In programming world, copy changes are usually the lowest possible priority thing, but with clients they're often some of the highest priority.
Yes, you could solve the problem that way. I normally solve it by releasing frequently. It's pretty rare that people mind waiting a few days. Or if they need to change copy a lot, by putting the copy in a content management system, so they can change it whenever they get the urge.
I can't make your change right now because I have a ton of half-finished in-development code
I solve that by not having a ton of half-finished code. Ship early, ship often, I say.
Branching and merging adds a lot of overhead if your SCM isn't built to handle it.
As I've mentioned elsewhere in this thread, I agree that some version control systems are better than others at handling branches. But the awesomeness of your tools can never reduce the cost to zero, because much of the cost isn't in the software.
Yes, I'm not denying that git's branches have less overhead than subversion branches. But less is not zero, and mere software can't reduce branching cost to zero because much of the cost isn't in the software at all.
If I had to branch a lot, I would surely use the tool that was best at it. But if I can eliminate the cost of branching by not branching, that seems a much more effective to me.
So how would you handle maintaining a stable branch with a small amount of day-to-day changes at the same time as an experimental branch where live dev work is going on?
My first step would be to figure out why the team is unable to produce stable code every time they check in.
Larger projects with many developers require the ability to branch and merge large bodies of code. Larger projects with many developers require the ability to branch and merge large bodies of code.
Yes, and why is that?
It's because people have trouble forming teams and maintaining strong relationships in large groups. The cost of communication gets too high for humans to effectively maintain the shared understandings necessary to work smoothly together.
So again, branching is what you do when a group fails to work effectively as a team.
Personality conflicts may be the root-cause for you but is not the root for the majority of people that require such functionality. Simple fact is, branching and merging is required for complex software development.
I see. Please link to your data proving these are facts, because they look a lot like your personal opinions to me.
I constantly branch and merge even when I am the only one working on a codebase. When branching and merging are so easy why wouldn't you take advantage of it?
I do, too. I call it "checking out" and "committing". I do it every few hours.
If branching is increasing your workload instead of making things easier you are most likely not using a source control system that is good at branching and merging.
When I'm building a unified product, what need would I have of branching and merging? If I'm not sure if something is a good enough idea to build, I don't build it. Or I build a quick, throw-away implementation to check an idea out. And then I throw it away.
No matter how good a source control system is at branching and merging, it can't solve the real cost: maintaining a understanding of different, semi-incongruent notions of the project, and then resolving those differences. The whole point of branching is to increase complexity, and excess complexity is the enemy of every good software project. As Occam's razor says, you shouldn't multiply entities beyond that which is strictly necessary.
That's not to say I never branch. But it's always a last resort for me, no matter how awesome the source control system is.
Trying to make git within that model is just adding complexity without getting the benefits.
Bless you for saying so.
Last year I nearly had to murder somebody because he was pushing git for 6 guys in the same office producing a web site that released weekly. I agreed that git was cool, and were I doing a distributed project, especially an open-source one, I'd love to use it. But I just couldn't see the value for a bunch of guys who worked off of trunk, were on the same LAN, had exactly one version in production, and checked in between a few times a day and a couple times a week.
If people feel there is a value for a team in that situation, let me know, as I'd love to hear about it.
I know that's not reasonable for every situation, but about 90% of the time I see people doing lots of branching and merging, it's a response to screwed-up organizations or dysfunctional personal relationships. I saw one team move to git from subversion because, at the root, a couple of developers were arrogant assholes and their manager was a chinless milquetoast who let them get away with it.
That's not to say git isn't awesome for certain situations, mind you. But branching and merging adds a fair bit of overhead, and anything that increases a project's overhead should be your last resort, not your first.
Cheap shot. Oracle makes arguably the best database software in the world. The thing is, not everybody needs the best database software in the world. Probably the majority can settle for a lot less.
Absolutely. Once Oracle stops marketing it to people who don't need it, I'll stop making fun of stupid people giving them stupid amounts money.
Of course, at this point, it's not clear to me that anybody doing green-field work needs it. Even Stonebraker has made clear that the modern SQL database, in trying to be good for everything, isn't great at anything. And paying Oracle rates when it isn't great for your purpose doesn't seem like such a hot idea.
Still, they'll be able to milk large-company legacy situations for decades to come, which may give them enough time to transition away to new products. I hope so, as plenty of nice people work there.
Basic economic theory applies. Monopolies give worse service than marketplaces, and charge more for it. If you believe software support is some weird exception, feel free to demonstrate that.
During your call for technical support, Oracle may try to sell you consulting services at prices which can be over $500 per hour.
Unfortunately, Oracle Corporate Consulting has a reputation for being very expensive and using mediocre consultants.
I've never dealt with Oracle's in-house consultants, because I'm not dumb enough to spend good money on Oracle's software. But on occasions when I have been forced to deal with other large captive consulting/professional services groups, that's been my experience, too.
You can get excellent open-source consultants for less than half those rates. My guess is that $500/hr would get you the attention of pretty much any core open-source team member out there.
Yes, but that's not a throat to choke. That's relying on normal commercial give and take.
If you spend the kind of money on open-source support that you do on an Oracle license and support contract, you'll get a much higher grade of support.
Even better from the corporate perspective is that there are multiple players who can support and extend an open-source product. You can get somebody on staff. You can hire an outside company. You can hire the core developers, or a company they've set up. Competition means lower risk and lower cost.
If Oracle tells you no, you're just fucked. But if maintaining your own custom version is worth it to you, you can do it. You can even launch a fork.
That's what CFOs want to hear: that in the however-unlikely eventuality that there's a serious problem with software, you have a Throat to Choke.
I understand the theoretical value of this, but I have never heard of anybody suing their way past Microsoft's EULAs, or getting any sort of compensation for bugs, no matter how heinous. If you can point me to documented cases of that, I'd be fascinated.
Until I see that happening on a regular basis, as far as I'm concerned it's a distracting fantasy. Much more valuable to me has been the ability to pay people to fix bugs and add new features. A lawsuit might pay off five years from now, but getting a performance fix in can pay off this month.
To be honest, the chance of getting open source software into an environment that has to be so heavily audited and regulated is almost zero.
For what it's worth, I think this has more to do with your compliance auditors than any real necessity driven by SOX or HIPPA.
I have clients who work under SOX and HIPPA regulations, and they use open source software happily. If you've got a smart auditor and smart management, then only the software directly involved needs compliance at all. Nobody's using Firefox to prepare accounting statements or to store patient records, for example. And even there the auditors have never expressed a worry that I've heard about.
And that makes a lot of sense to me. Internally developed software is much more risky than a widely used open source package, as it typically has higher bug rates, lower levels of inspection, and programmers who have more motive and greater opportunity to do naughty things.
The idea that an armed populace could effectively fight a government trained and equipped army is patently ludicrous. Soccer moms and business men with pistols vs trained killers with tanks and artillery only ends one way.
Not true.
Look at the Branch Davidians at Waco, for example. Yeah, they ended up in the hurtlocker, but not in the way you're suggesting is inevitable, and their apparently unintentional deaths caused substantial outcry.
It's also hard to get soldiers to shoot at their fellow citizens, especially when out en masse. This is a huge complicating factor for China's gerontocrats; they do a great deal to avoid direct confrontation and mass demonstrations, because there's a substantial risk they'd lose. Not due to inferior firepower, but due to insufficient moral authority.
I think in those kinds of situations, firepower can hinder as often as it helps, but it definitely serves to make the state-controlled forces much more cautious. At the least, that extra caution requires many more soldiers to get the same results.
I think a good chunk of what you write is true, and I'd only object to calling an explanation of the current crisis (or at least what was the current crisis a week ago when you wrote that).
I agree we've overspent and will pay the price in a variety of ways, but that's the (coming) economic crisis rather than the (perhaps subsiding) financial crisis.
A piece of code can run flawlessly, be technically perfect and still not match the customers requirements.
This is true, but I think that should also be baked into the process. Rather then trying to get quality by testing it in later, you should have somebody in the room who knows what needs to get built, and they and developers should talk at least every few hours. They should also define success criteria before or as the working is being done and tests for that should get automated along with everything else.
But even that's no guarantee that you'll build what people need; that just guarantees you build what the suits asked for. The only solution is to ship early and often, and then pay careful attention to how people are using it in the real world.
I like programming just fine, but I code all damn day, 5 days a week. Why should it count against me that my interests are varied such that when I get home, I want to do something else?
Why should it count against you that another potential hire likes the work better?
I'd say it's because I'd expect them to be more productive, more engaged, and less likely to burn out. They'll take problems further, work on them longer, and care about the solutions more. Their outside interests will bring new ideas, create new opportunities, and give them a playground that isn't the production code base.
For some jobs, being a clock puncher is probably fine. I'd rather deal with the grocery store cashier who likes her work, but the ones for whom it's just a job are ok, too. But for serious software development, there are a host of reasons you should only hire the very best people you can get. And part of being the best at something is loving it.
Pick a technology you find interesting and build an application in it.
Amen to that. When I'm interviewing people, my main concern is that they can do the work. If that's job experience, that's great. But as long as you have to maintain code in production, then that's the main thing.
Personally, I have a mild bias toward hiring people with hobby projects. It shows that they're doing the work because they like it, and it lets me see what they can do themselves. With a resume item, it's always hard to tell who did what, but with a solo or open-source project, it's much clearer.
Management is always begging QA and engineering to try and come up with ways to automate testing of these things, but no one ever gets anywhere.
Yes, the fact that you aren't getting anywhere is proof that it's impossible for everybody, everywhere. Or, just maybe, it could mean that you are too busy to do it right. Or are using toolkits that weren't built with testability in mind. Or are spending so much time on bugs and QA that you can't afford to invest in tests. Or that you need an outside expert to help you get started.
There are so many things that simply cannot be tested except by a human.
That's not true. All repeatable tests must be defined by a thoughtful human, but there's no theoretical reason that once defined they can't be run by a computer.
All of the examples you give can be solved that way. You put the subjective information in tests. The computer may not know whether the A/V sync is right, but it can tell whether it's close enough to what a human said is right.
All-in-all, a major update to the player can require over two months of QA by a team of 8 testers.
I think "require" is a little strong. The one kind of testing a computer can't yet do is exploratory testing, where you look at the product and find the things that aren't expressed in tests yet. But for the person-following-a-script tests, the most I'll grant is that it might be cheaper to use humans than to automate. Which is a legitimate business decision, but it doesn't make the other approaches impossible.
This is one of the funniest things I have ever read. You're not being serious, right?
Even if he isn't, I am. I know of a number of teams who work like this. There are a number of teams who report defect-in-production levels lower than one per developer-month.
Key practices to get to that level include test-driven development, pair programming (or code reviews), continuous integration, and frequent releases. Plus all the tests the other guy mentioned.
My feeling is that if you need a database to keep track of all your mistakes, you should focus on making fewer mistakes.
Slashdot Mirror
Which part would you like data on?
The bit about relationships not scaling is well documented. The studies most interesting to me are the ones that suggest it is an evolved limit. If you'd like a general introduction, pretty much any introductory cultural anthropology text would cover that. Or you could dive right in with Co-evolution of Neocortex Size, Group Size, and Language in Humans and the references from there.
Software companies often need to create large, new features, and don't wish to destabilize the core product.
Solution: stop checking in stuff that doesn't work. I do this through unit testing, acceptance testing, pair programming, working within a few paces of a product manager, and a few other practices.
Or it's because it's *far* easier for developers to be able to branch pieces of code, work on feature or bugfix development in their own little playpen.
I don't have anything against local copies. It's kinda hard to change the code if you can't change the code.
being able to revert a messed up piece of code is awfully handy
True. I use an IDE with undo for small cases of this, and reversion to head for large versions. But I think a better solution is to find mistakes early, so that screwing up is easy to fix.
This also facilitates easier code review
This is true only if you're willing to pay the cost of slower code review. Longer feedback loops inevitably create greater waste than shorter ones.
Or because, in a more contract-oriented world, they might need to build customized applications for customers, and branch-and-merge strategies make that kind of code management possible.
I have never seen that not be the road to maintenance hell. For the customized versions of products I've worked on, it's not like customers don't want all the bug fixes and new features that you're putting into the app. They do, just with their customizations. Trying to juggle all that through branching and merging seems like a lot more work than just making the software configurable, templatable, or customizable directly.
Honestly, if you've never seen the need to branch-and-merge, you've never worked on a large project. Period.
I don't remember saying I've never seen the need for that. Perhaps you replied to the wrong post?
That may work fine when you're the only one working on the code, but if you're working with someone else, and he's committed code that you don't think is any good (or at least not ready for production yet), but later commits from you are, then with a single trunk you're simply out of luck.
This is back to my original point. If I'm working with people who are regularly checking in bad code, then I solve that by talking with the person. Why would I let him go on doing dumb things any longer than necessary?
But what if you've been working on something that seemed like a good idea at the time, and suddenly you realise you're going completely in the wrong direction and need to undo a lot of commits (but you want to keep the other bugfixes you did)? Or what if someone else is working on the same project?
I mainly solve this by making sure it doesn't happen much. Branching can only save you if you realize it's a bad idea before you merge to trunk, only if your changes are mostly bad. I think the solution to bad ideas is better product management, not better version control.
Have you read what you just wrote here? Ofcourse the point of branching is not to increase complexity. It's to reduce it.
Let's take a simple example. Me and my team are developing against trunk, committing every few hours, and shipping weekly. How many relevant versions of the software are there?
I count 2. One's in production, and one's at the head of the trunk. The divergence between the two is at maximum, however much the team can develop in a week.
Now I branch. How many interesting versions are there? I count 3. How much divergence is there? Well, there's release to head, release to branch, and branch to head.
So that's 2 versions with 1 axis of divergence, versus 3 versions with 3 axes of divergence.
No matter how you measure it, that is increased complexity.
Easily, the most common reason for branching is a stable-versus-development split.
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
I've run into that a million times with copy changes. In programming world, copy changes are usually the lowest possible priority thing, but with clients they're often some of the highest priority.
Yes, you could solve the problem that way. I normally solve it by releasing frequently. It's pretty rare that people mind waiting a few days. Or if they need to change copy a lot, by putting the copy in a content management system, so they can change it whenever they get the urge.
I can't make your change right now because I have a ton of half-finished in-development code
I solve that by not having a ton of half-finished code. Ship early, ship often, I say.
Branching and merging adds a lot of overhead if your SCM isn't built to handle it.
As I've mentioned elsewhere in this thread, I agree that some version control systems are better than others at handling branches. But the awesomeness of your tools can never reduce the cost to zero, because much of the cost isn't in the software.
So again, branching is what you do when a group fails to work effectively as a team.
Sorry to reply to myself here, but although that makes sense in the context of what I'm saying, taken on its own it would overstate the case.
More precisely, I mean that when a group fails effectively to work as a team, branching is a popular solution.
Yes, I'm not denying that git's branches have less overhead than subversion branches. But less is not zero, and mere software can't reduce branching cost to zero because much of the cost isn't in the software at all.
If I had to branch a lot, I would surely use the tool that was best at it. But if I can eliminate the cost of branching by not branching, that seems a much more effective to me.
So how would you handle maintaining a stable branch with a small amount of day-to-day changes at the same time as an experimental branch where live dev work is going on?
My first step would be to figure out why the team is unable to produce stable code every time they check in.
Larger projects with many developers require the ability to branch and merge large bodies of code. Larger projects with many developers require the ability to branch and merge large bodies of code.
Yes, and why is that?
It's because people have trouble forming teams and maintaining strong relationships in large groups. The cost of communication gets too high for humans to effectively maintain the shared understandings necessary to work smoothly together.
So again, branching is what you do when a group fails to work effectively as a team.
Personality conflicts may be the root-cause for you but is not the root for the majority of people that require such functionality. Simple fact is, branching and merging is required for complex software development.
I see. Please link to your data proving these are facts, because they look a lot like your personal opinions to me.
I constantly branch and merge even when I am the only one working on a codebase. When branching and merging are so easy why wouldn't you take advantage of it?
I do, too. I call it "checking out" and "committing". I do it every few hours.
If branching is increasing your workload instead of making things easier you are most likely not using a source control system that is good at branching and merging.
When I'm building a unified product, what need would I have of branching and merging? If I'm not sure if something is a good enough idea to build, I don't build it. Or I build a quick, throw-away implementation to check an idea out. And then I throw it away.
No matter how good a source control system is at branching and merging, it can't solve the real cost: maintaining a understanding of different, semi-incongruent notions of the project, and then resolving those differences. The whole point of branching is to increase complexity, and excess complexity is the enemy of every good software project. As Occam's razor says, you shouldn't multiply entities beyond that which is strictly necessary.
That's not to say I never branch. But it's always a last resort for me, no matter how awesome the source control system is.
For entering raw binary, start with stty's man page.
Trying to make git within that model is just adding complexity without getting the benefits.
Bless you for saying so.
Last year I nearly had to murder somebody because he was pushing git for 6 guys in the same office producing a web site that released weekly. I agreed that git was cool, and were I doing a distributed project, especially an open-source one, I'd love to use it. But I just couldn't see the value for a bunch of guys who worked off of trunk, were on the same LAN, had exactly one version in production, and checked in between a few times a day and a couple times a week.
If people feel there is a value for a team in that situation, let me know, as I'd love to hear about it.
Try merging a reasonably-sized branch with subversion (and you'll fail and cry and ask why oh why you didnt use git).
Simpler solution: stop merging reasonably-sized branches.
I know that's not reasonable for every situation, but about 90% of the time I see people doing lots of branching and merging, it's a response to screwed-up organizations or dysfunctional personal relationships. I saw one team move to git from subversion because, at the root, a couple of developers were arrogant assholes and their manager was a chinless milquetoast who let them get away with it.
That's not to say git isn't awesome for certain situations, mind you. But branching and merging adds a fair bit of overhead, and anything that increases a project's overhead should be your last resort, not your first.
Cheap shot. Oracle makes arguably the best database software in the world. The thing is, not everybody needs the best database software in the world. Probably the majority can settle for a lot less.
Absolutely. Once Oracle stops marketing it to people who don't need it, I'll stop making fun of stupid people giving them stupid amounts money.
Of course, at this point, it's not clear to me that anybody doing green-field work needs it. Even Stonebraker has made clear that the modern SQL database, in trying to be good for everything, isn't great at anything. And paying Oracle rates when it isn't great for your purpose doesn't seem like such a hot idea.
Still, they'll be able to milk large-company legacy situations for decades to come, which may give them enough time to transition away to new products. I hope so, as plenty of nice people work there.
Basic economic theory applies. Monopolies give worse service than marketplaces, and charge more for it. If you believe software support is some weird exception, feel free to demonstrate that.
As one example, consider this page. They say:
During your call for technical support, Oracle may try to sell you consulting services at prices which can be over $500 per hour.
Unfortunately, Oracle Corporate Consulting has a reputation for being very expensive and using mediocre consultants.
I've never dealt with Oracle's in-house consultants, because I'm not dumb enough to spend good money on Oracle's software. But on occasions when I have been forced to deal with other large captive consulting/professional services groups, that's been my experience, too.
You can get excellent open-source consultants for less than half those rates. My guess is that $500/hr would get you the attention of pretty much any core open-source team member out there.
Yes, but that's not a throat to choke. That's relying on normal commercial give and take.
If you spend the kind of money on open-source support that you do on an Oracle license and support contract, you'll get a much higher grade of support.
Even better from the corporate perspective is that there are multiple players who can support and extend an open-source product. You can get somebody on staff. You can hire an outside company. You can hire the core developers, or a company they've set up. Competition means lower risk and lower cost.
If Oracle tells you no, you're just fucked. But if maintaining your own custom version is worth it to you, you can do it. You can even launch a fork.
That's what CFOs want to hear: that in the however-unlikely eventuality that there's a serious problem with software, you have a Throat to Choke.
I understand the theoretical value of this, but I have never heard of anybody suing their way past Microsoft's EULAs, or getting any sort of compensation for bugs, no matter how heinous. If you can point me to documented cases of that, I'd be fascinated.
Until I see that happening on a regular basis, as far as I'm concerned it's a distracting fantasy. Much more valuable to me has been the ability to pay people to fix bugs and add new features. A lawsuit might pay off five years from now, but getting a performance fix in can pay off this month.
To be honest, the chance of getting open source software into an environment that has to be so heavily audited and regulated is almost zero.
For what it's worth, I think this has more to do with your compliance auditors than any real necessity driven by SOX or HIPPA.
I have clients who work under SOX and HIPPA regulations, and they use open source software happily. If you've got a smart auditor and smart management, then only the software directly involved needs compliance at all. Nobody's using Firefox to prepare accounting statements or to store patient records, for example. And even there the auditors have never expressed a worry that I've heard about.
And that makes a lot of sense to me. Internally developed software is much more risky than a widely used open source package, as it typically has higher bug rates, lower levels of inspection, and programmers who have more motive and greater opportunity to do naughty things.
The idea that an armed populace could effectively fight a government trained and equipped army is patently ludicrous. Soccer moms and business men with pistols vs trained killers with tanks and artillery only ends one way.
Not true.
Look at the Branch Davidians at Waco, for example. Yeah, they ended up in the hurtlocker, but not in the way you're suggesting is inevitable, and their apparently unintentional deaths caused substantial outcry.
It's also hard to get soldiers to shoot at their fellow citizens, especially when out en masse. This is a huge complicating factor for China's gerontocrats; they do a great deal to avoid direct confrontation and mass demonstrations, because there's a substantial risk they'd lose. Not due to inferior firepower, but due to insufficient moral authority.
I think in those kinds of situations, firepower can hinder as often as it helps, but it definitely serves to make the state-controlled forces much more cautious. At the least, that extra caution requires many more soldiers to get the same results.
I think a good chunk of what you write is true, and I'd only object to calling an explanation of the current crisis (or at least what was the current crisis a week ago when you wrote that).
I agree we've overspent and will pay the price in a variety of ways, but that's the (coming) economic crisis rather than the (perhaps subsiding) financial crisis.
A piece of code can run flawlessly, be technically perfect and still not match the customers requirements.
This is true, but I think that should also be baked into the process. Rather then trying to get quality by testing it in later, you should have somebody in the room who knows what needs to get built, and they and developers should talk at least every few hours. They should also define success criteria before or as the working is being done and tests for that should get automated along with everything else.
But even that's no guarantee that you'll build what people need; that just guarantees you build what the suits asked for. The only solution is to ship early and often, and then pay careful attention to how people are using it in the real world.
I like programming just fine, but I code all damn day, 5 days a week. Why should it count against me that my interests are varied such that when I get home, I want to do something else?
Why should it count against you that another potential hire likes the work better?
I'd say it's because I'd expect them to be more productive, more engaged, and less likely to burn out. They'll take problems further, work on them longer, and care about the solutions more. Their outside interests will bring new ideas, create new opportunities, and give them a playground that isn't the production code base.
For some jobs, being a clock puncher is probably fine. I'd rather deal with the grocery store cashier who likes her work, but the ones for whom it's just a job are ok, too. But for serious software development, there are a host of reasons you should only hire the very best people you can get. And part of being the best at something is loving it.
Pick a technology you find interesting and build an application in it.
Amen to that. When I'm interviewing people, my main concern is that they can do the work. If that's job experience, that's great. But as long as you have to maintain code in production, then that's the main thing.
Personally, I have a mild bias toward hiring people with hobby projects. It shows that they're doing the work because they like it, and it lets me see what they can do themselves. With a resume item, it's always hard to tell who did what, but with a solo or open-source project, it's much clearer.
Have you EVER worked on commercial software?
I have, and his comments are not unreasonable.
Management is always begging QA and engineering to try and come up with ways to automate testing of these things, but no one ever gets anywhere.
Yes, the fact that you aren't getting anywhere is proof that it's impossible for everybody, everywhere. Or, just maybe, it could mean that you are too busy to do it right. Or are using toolkits that weren't built with testability in mind. Or are spending so much time on bugs and QA that you can't afford to invest in tests. Or that you need an outside expert to help you get started.
There are so many things that simply cannot be tested except by a human.
That's not true. All repeatable tests must be defined by a thoughtful human, but there's no theoretical reason that once defined they can't be run by a computer.
All of the examples you give can be solved that way. You put the subjective information in tests. The computer may not know whether the A/V sync is right, but it can tell whether it's close enough to what a human said is right.
All-in-all, a major update to the player can require over two months of QA by a team of 8 testers.
I think "require" is a little strong. The one kind of testing a computer can't yet do is exploratory testing, where you look at the product and find the things that aren't expressed in tests yet. But for the person-following-a-script tests, the most I'll grant is that it might be cheaper to use humans than to automate. Which is a legitimate business decision, but it doesn't make the other approaches impossible.
This is one of the funniest things I have ever read. You're not being serious, right?
Even if he isn't, I am. I know of a number of teams who work like this. There are a number of teams who report defect-in-production levels lower than one per developer-month.
Key practices to get to that level include test-driven development, pair programming (or code reviews), continuous integration, and frequent releases. Plus all the tests the other guy mentioned.
My feeling is that if you need a database to keep track of all your mistakes, you should focus on making fewer mistakes.