I actually have the same approach.. I have too many people in my life that leave the stupidest voice mails (trying to be funny, info i don't need, just saying hi)....
Interesting! Given the number of replies, this seems like a common situation.
I guess this must partly be a volume thing. In both my work and personal lives, the primary means of remote communication is email. So the number of voicemails I get is pretty small. The ones I do get tend to be relatively important. But living in San Francisco and doing computer work I guess I must be at the email-heavy end of things.
One thing I love about email is the ability to skim and then dash off a quick reply, so I can be polite but not waste much time. If I had to deal with my volume of email as voicemail instead, I guess I'd be similarly willing to delete most stuff unheard.
Totally reasonable thing to worry about. Maybe I'm still stuck too much in the past here, but the problem that still worries me more is the people who don't have good unit and acceptance test coverage. On the other hand, if a team were prone to Silver Bullet Syndrome, then perhaps their unit tests wouldn't be what I'd call good anyhow. Could you say more about what you've seen in the field that worries you?
Sorry, no. He's got a publisher with the balls to let him write what he wants to, and willing to sell it to people who appreciate it.
I don't buy it. Although I loved Snow Crash, I think there were editing problems all over that thing. And for Diamond Age, any editor with starch would have looked at the last chapter and said, "Seriously? That's how you're going to end this? Take two weeks of vacation and then we'll talk." That wasn't meant to be savored; it was meant to get him done with the book ASAP.
The upside of a weak editor is that we get a lot of nice bits that another editor might have cut. The digression in Diamond Age into the label of the steak sauce in the pub during lunch with Napier and the Duke was one of those that pleased me particularly.
However, at some point one has to trim enough to get a manageable book out the door. A fine French meal is meant to be savored, too, but there's a reason none of them run to a 230 courses over a continuous 48 hours at the table. I know a lot of heavy readers, serious readers, and 75% of them didn't even bother starting the third volume of the Baroque Cycle. After two volumes, they'd had more than their fill.
just limit yourself to comic books or something you can handle while in the bathroom
Was there some particular need to be a prick about this? The other guy's comment seemed like a reasonable statement of personal preference.
as if he spent a years carefully writing each novel until his publisher suddenly showed up at his door and said "Dude, you've got 24 hours to finish this novel."
My interpretation has always been that he just got sick and tired of the whole project and said, "Fuck it! What's the shortest path here between me and a payday?"
You will never be able to get the telemarketing people off your back then, since they now can fill up your voicemail with their messages without having to experience that you hang up on them.
Probably not a big worry. Telemarketing thrives on abusing human politeness.
A nice old lady has a hard time saying no, or thinking straight with a mile-a-minute, hard-to-interrupt speech on whatever garbage the telemarketer is selling. They get their money by demanding direct action from you in the instant; none of them just politely leave a number and ask you to call them back later.
With voicemail, you can easily delete a message without the same social pain that you get from hanging up on somebody. So there's a lot less benefit in voicemail spam than there is in live calls.
I don't think I -ever- check my voicemail unless I've accidentally missed a call I know is important, and almost nobody I know checks theirs on their personal cell either.
Seriously? Whenever I see the little voicemail icon lit up, I check it. You really just ignore the messages until they get auto-deleted unless you think there's something especially good in there?
I think this is good for the times when you want to quickly leave a person a message without wanting to disturb them.
That's exactly what I want. No disturbance, no conversation, just leaving them a quick note. Just like I can do with email. It dumbfounds me that we call it "voice mail" when the behavior is pure 1970s answering machine, and nothing like postal mail or electronic mail.
The biggest disadvantage to agile that I see is that, if you have lots of customers (think MS Word, or slightly more niche, Solaris OS), you can't really get feedback from all of them (and even if you could they want different things).
If you have a lot of customers, you don't need to get feedback from them all. Instead, you have product managers who give feedback to the development team based on a variety of inputs, including customer research, user testing, interaction with user groups, user surveys, and competitive analysis.
For feedback on stuff under development, the interaction design world has plenty of tools for figuring out what sub-groups you need to test your software on and how to do that effectively.
You can also run beta programs and the like so that your early-adopter customers can give you plenty of feedback, while the more conservative types wait for stable releases. A good example of that latter one is IntelliJ IDEA and their Early Access program.
Also, you can't really release a new version of an OS frequently.
Yep. Totally impossible. Except that Red Hat has been doing that for years. The Fedora series releases every six months, with beta releases more frequent than that. And new patches pretty much every night. They then use that to provide more stable releases, the Red Hat Enterprise Linux series to their customers who want more stability.
I've found this only works if you have a client who doesn't want to force you into a fixed bid contract.
After a lot of years developing software, I have never even heard of a fixed bid software job where everybody ended up happy. Every one I have seen up close has ended up with at least one side feeling like they got screwed, and generally both sides feel that way.
The good news is that there are other options. This book has some great options for software development contracts that work in an Agile context.
I'm not appealing; I'm actually and directly ridiculing your suggestion that it's all a ginormous big oil conspiracy.
Perhaps there's nothing there at all. There's some data that says there might be.
There's some data that says people might be able to read minds. There's some data that says maybe dinosaurs and humans walked the earth at the same time. There's some data that says there might be canals on Mars. The preponderance of evidence is that none of those are true, and that cold fusion is more of the same bunk.
That you're bringing up stale conspiracy theories to explain the lack of progress isn't proof that there's something to cold fusion; it's evidence that cold fusion can safely dismissed like every other theory popular with the nut-jobs.
But, another equally likely scenario is that this sort of fast development cycle was impossible back then. Many of the tools and languages advocated by Agile proponents and Web 2.0 startups have only come into prominence over the last few years. One of the most important things for Agile development is thorough, robust tool support.
As you can see from my comments elsewhere in this thread, I think the new tools have made uptake easier. But the tools aren't particularly important; good Agile teams existed long before the modern tools. Indeed, they were only invented because of those Agile teams. Even if you took away my refactoring tools and my unit test frameworks, I'd still be releasing early and often; my productivity would just be lower.
Wishful thinking, perhaps? You can never make any change completely fearlessly in most projects. Unit tests can do a lot to help increase your confidence and catch bugs early, but they are not a substitute for knowing what you're doing and understanding its implications, and neither are they foolproof.
Well, I did also say acceptance tests, which I think are also very valuable. I never suggested that they were a substitute for knowing what you're doing. It's true that they aren't foolproof; maybe it's just me, but I discourage hiring fools.
For one thing, it's impossible to get 100% test coverage for most projects. If you don't have full coverage, you can always break something in a gap.
This is true. From talking to people who do insurance company work, the kind of bug rates you can get get from doing unit and acceptance testing are already worlds better than what they are used to, and it may be enough for their environment. If not, there are other practices to do. I said they would be the first thing I did, not the only thing.
For another thing, if you have a few thousand lines of code and you're worried enough about bugs to write a few thousand more lines of unit tests, how can you possibily be confident that the extra few thousand lines are themselves bug-free and testing what you think you're testing?
Personally, I would be confident because I wrote them using test-driven development and pair programming on a team that uses collective code ownership, so all the code had been reviewed throughly. Also, because we would build along with them end-to-end acceptance tests that were defined by product experts. And were I cleaning up a legacy code base, I would check code coverage both the basic way and through a tool that randomly mutates code and looks for test failures, as well as through manual inspection.
That doesn't mean that I'd expect this to be perfect. Nothing is. But with that kind of coverage and related supporting practices, I'd expect bug-in-production rates to be between one per developer-month and one per month. That's been my previous experience, and that's more than good enough for most teams. If it weren't, I'd do more.
How does this work in regulated industries like insurance where changes affecting pricing and eligibility require filing updates to the manual with each state's Department of Insurance?
Good question. Maybe somebody who does that kind of work can speak up, but here's my take:
My first move would be to put a bunch of unit and acceptance tests around pricing and eligibility code. If we know we can't accidentally trigger a regulatory refiling, then we could change the system in other ways fearlessly.
Once you know you can't break things accidentally, then it seems like you could throw the question back in the laps of the guys in suits. If they request a change that requires re-filing everything, then you tell them so. If they want it, that's great. If not, that's also great.
I guess it's safe to assume that the internal website isn't subject to SOX compliance requirements...
It depends on your SOX auditor, but if you've got a sane one, there's no reason you can't follow an agile process with, at most, minor modifications from what you'd see in an Extreme Programming book.
And it's good to remember that nothing of this has anything to do with Web 2.0:)
I think the one tie is that before Web 2.0 a lot of people would hear about these approaches and say "unpossible!" Now that you can point to plenty of successes that work like this, people can't be as casually dismissive.
Your evidence is one 9-year-old article by some low-rent technology journalist about the giant oil-company/hot-fusion conspiracy against fusion? Please.
Right now there is more investment in any and every half-baked energy plan than there has ever been. The Economist magazine just did a 14-page special section listing all of the exciting options. If the conditions were ever such that large companies could suppress promising energy research, they have since passed.
user involvement is still handled by marketing and trickles down to R&D at a slowly and ambiguously. I see this as our weak point.
You're right; that is a common mistake.
In my view, Agile development is all about making feedback loops effective and fast. Even if you're releasing software regularly, that isn't enough; you have to see how it's affecting the users. Maybe that means developers are directly involved and maybe not, but you should certainly be sitting within easy conversational distance of somebody who does spend a lot of time studying your users.
In short, you're right: going faster doesn't help if you don't look where it's getting you and steer accordingly.
I'm not impressed with the "perpetual beta" and "using your users for Q/A" concept. Remember, the users can leave.
The upside is that if you do it right, they're more involved than ever. Google was in beta for years, as was Flickr. I was fine with that; being an early adopter and watching the product evolve was exciting, especially when they did something in response to user feedback.
I think this has more to do with the free man-hours devs get from users testing amd troubleshooting their products, then anything else, really.
That's definitely one source of benefit. And generally, people are happy to give it. There are a variety of beta-quality products I use, and am glad to give early feedback because it helps me get a product more in line with what I want. When I don't have the time to deal with beta-quality stuff, I pay up for a finished product.
From a developer perspective, I love this, too. You never really know what people are going to do with something until you give it to them. If you're Microsoft, you'll sit there piling up several years' worth of guesses, and then find out all at once how you did. I think it's much safer and saner to release early and often, so you can correct your small problems before they become big ones. If I had to pay users to do that, I probably would, but so far, there seem to be plenty of free ones.
And with all of these little incremental updates, how do you not kick all of your users off of the system repeatedly? Sit around and wait for everyone to log off?
Depends on your technology, but by and large you build things in such a way that you can shift load around without people noticing. In web-land, that's generally done with load balancer tricks when upgrading the front end, and a smart service layer when upgrading back-end apps.
I hate the bombardment of updates I have to run now. Windows, Adobe, some install manager, Adobe, Java, Abobe... You get the idea.
Well, I'd more call this "Agile done stupid". It's possible to make automatic update processes pretty much seamless from the user's perspective. That some companies aren't good at paying attention to what the user actually wants is a problem that predates Agile methods.
So companies that like to sell software based on 12-18 month releases will never move to a true "agile" development...
I don't think that's necessarily the case. The excellent Java IDE has release and early-access versions. The release version costs money and has a new version every year or so. The early-access version is free, beta quality, comes out frequently, and expires every month or so. Users can pick whether they want stability or features more. This has been working well for them for the last few years, and could see it working well for a lot of people.
For instance, my company develops health care diagnostic solutions, some of which are heavily regulated. While many of our tools and products could highly benefit from this design approach, federal regulations simply make it an impossibility.
You'd be surprised. There are a number of medical device people who are active in the Agile world. Yes, you can't push new code to somebody's pacemaker every morning, so there are some limits. But they are definitely applying Agile lessons even in heavily regulated spaces, so it's worth checking them out.
This has nothing to do with Web 2.0 and is instead similar to the Agile software development process.
Yes and no. It's true that the Agile people had this pretty well figured out well before the Web 2.0 wave.
However, part of the reason that Agile methods have so much uptake is that the Web 2.0 companies are releasing early and often, both showing that it can be done and forcing their competitors to step up the pace. I also give some credit to the Rails people, who built a framework that supports key Agile practices like unit testing and short feedback loops.
I wish all this was true. Incremental and fast and includes clients. Sounds like a recipe for disaster to me. Sorry but I really have not seen development teams using such methods successfully.
Works for me. It requires supporting disciplines, though. In my view, that includes a well-meshed team, a very disciplined product management process, strong automated testing, a relentless devotion to code quality, and continual examination of your architectural choices.
It also works for plenty of other people. Flickr released every few hours, and they ended up selling for $20m after 18 months of work. YouTube releases once a week for interface changes and once a month for database changes, and they always have. At a billion views a day, I'd call them pretty successful.
I never understood these. What's wrong with typing 'make test' frequently? But yeah, "don't check in broken stuff into mainline" is good advice.
It's not one or the other; you do both. A CI server saves you from the people who forget to do that. And it saves you from screwing things up for other people when you forget to check in a file or have some weird environment difference on your own machine.
Without a CI server, either the fussiest person becomes the bad cop, yelling at the less careful and ending up resented. Or things just stay broken forever until the final push. With a CI server, the machine does the grumbling instantly, freeing the fussiest person to do real work. As somebody who is frequently the team fussbudget, I love not having to prod people all the time. And I love that the machine makes me live up to my own high standards.
Of course, I'd expect people to learn from each other, so they write more similar code over time.
We're on the same page here. The best teams I see definitely do end up evolving a common style and own the code collectively, so you really can't tell.
I phrased it the way I did, in terms of nice chats and eventual convergence, because the rock I'm trying to steer him around is the clash you get when people believe their personal stylistic preferences are inviolable laws of nature. Indulge that and you end up with code silos, mutual irritation, and lower productivity.
To work together as an effective team, they will need enough of a shared style that they are comfortable working in each other's code. Solving the points of difference now will make it much easier to add a third or fourth developer, and it will also ease the transition when one of them decides to move on.
Slashdot Mirror
I actually have the same approach.. I have too many people in my life that leave the stupidest voice mails (trying to be funny, info i don't need, just saying hi)....
Interesting! Given the number of replies, this seems like a common situation.
I guess this must partly be a volume thing. In both my work and personal lives, the primary means of remote communication is email. So the number of voicemails I get is pretty small. The ones I do get tend to be relatively important. But living in San Francisco and doing computer work I guess I must be at the email-heavy end of things.
One thing I love about email is the ability to skim and then dash off a quick reply, so I can be polite but not waste much time. If I had to deal with my volume of email as voicemail instead, I guess I'd be similarly willing to delete most stuff unheard.
Totally reasonable thing to worry about. Maybe I'm still stuck too much in the past here, but the problem that still worries me more is the people who don't have good unit and acceptance test coverage. On the other hand, if a team were prone to Silver Bullet Syndrome, then perhaps their unit tests wouldn't be what I'd call good anyhow. Could you say more about what you've seen in the field that worries you?
Sorry, no. He's got a publisher with the balls to let him write what he wants to, and willing to sell it to people who appreciate it.
I don't buy it. Although I loved Snow Crash, I think there were editing problems all over that thing. And for Diamond Age, any editor with starch would have looked at the last chapter and said, "Seriously? That's how you're going to end this? Take two weeks of vacation and then we'll talk." That wasn't meant to be savored; it was meant to get him done with the book ASAP.
The upside of a weak editor is that we get a lot of nice bits that another editor might have cut. The digression in Diamond Age into the label of the steak sauce in the pub during lunch with Napier and the Duke was one of those that pleased me particularly.
However, at some point one has to trim enough to get a manageable book out the door. A fine French meal is meant to be savored, too, but there's a reason none of them run to a 230 courses over a continuous 48 hours at the table. I know a lot of heavy readers, serious readers, and 75% of them didn't even bother starting the third volume of the Baroque Cycle. After two volumes, they'd had more than their fill.
just limit yourself to comic books or something you can handle while in the bathroom
Was there some particular need to be a prick about this? The other guy's comment seemed like a reasonable statement of personal preference.
as if he spent a years carefully writing each novel until his publisher suddenly showed up at his door and said "Dude, you've got 24 hours to finish this novel."
My interpretation has always been that he just got sick and tired of the whole project and said, "Fuck it! What's the shortest path here between me and a payday?"
You will never be able to get the telemarketing people off your back then, since they now can fill up your voicemail with their messages without having to experience that you hang up on them.
Probably not a big worry. Telemarketing thrives on abusing human politeness.
A nice old lady has a hard time saying no, or thinking straight with a mile-a-minute, hard-to-interrupt speech on whatever garbage the telemarketer is selling. They get their money by demanding direct action from you in the instant; none of them just politely leave a number and ask you to call them back later.
With voicemail, you can easily delete a message without the same social pain that you get from hanging up on somebody. So there's a lot less benefit in voicemail spam than there is in live calls.
I don't think I -ever- check my voicemail unless I've accidentally missed a call I know is important, and almost nobody I know checks theirs on their personal cell either.
Seriously? Whenever I see the little voicemail icon lit up, I check it. You really just ignore the messages until they get auto-deleted unless you think there's something especially good in there?
I think this is good for the times when you want to quickly leave a person a message without wanting to disturb them.
That's exactly what I want. No disturbance, no conversation, just leaving them a quick note. Just like I can do with email. It dumbfounds me that we call it "voice mail" when the behavior is pure 1970s answering machine, and nothing like postal mail or electronic mail.
The biggest disadvantage to agile that I see is that, if you have lots of customers (think MS Word, or slightly more niche, Solaris OS), you can't really get feedback from all of them (and even if you could they want different things).
If you have a lot of customers, you don't need to get feedback from them all. Instead, you have product managers who give feedback to the development team based on a variety of inputs, including customer research, user testing, interaction with user groups, user surveys, and competitive analysis.
For feedback on stuff under development, the interaction design world has plenty of tools for figuring out what sub-groups you need to test your software on and how to do that effectively.
You can also run beta programs and the like so that your early-adopter customers can give you plenty of feedback, while the more conservative types wait for stable releases. A good example of that latter one is IntelliJ IDEA and their Early Access program.
Also, you can't really release a new version of an OS frequently.
Yep. Totally impossible. Except that Red Hat has been doing that for years. The Fedora series releases every six months, with beta releases more frequent than that. And new patches pretty much every night. They then use that to provide more stable releases, the Red Hat Enterprise Linux series to their customers who want more stability.
I've found this only works if you have a client who doesn't want to force you into a fixed bid contract.
After a lot of years developing software, I have never even heard of a fixed bid software job where everybody ended up happy. Every one I have seen up close has ended up with at least one side feeling like they got screwed, and generally both sides feel that way.
The good news is that there are other options. This book has some great options for software development contracts that work in an Agile context.
Nice try at Appeal to Ridicule, though.
I'm not appealing; I'm actually and directly ridiculing your suggestion that it's all a ginormous big oil conspiracy.
Perhaps there's nothing there at all. There's some data that says there might be.
There's some data that says people might be able to read minds. There's some data that says maybe dinosaurs and humans walked the earth at the same time. There's some data that says there might be canals on Mars. The preponderance of evidence is that none of those are true, and that cold fusion is more of the same bunk.
That you're bringing up stale conspiracy theories to explain the lack of progress isn't proof that there's something to cold fusion; it's evidence that cold fusion can safely dismissed like every other theory popular with the nut-jobs.
But, another equally likely scenario is that this sort of fast development cycle was impossible back then. Many of the tools and languages advocated by Agile proponents and Web 2.0 startups have only come into prominence over the last few years. One of the most important things for Agile development is thorough, robust tool support.
As you can see from my comments elsewhere in this thread, I think the new tools have made uptake easier. But the tools aren't particularly important; good Agile teams existed long before the modern tools. Indeed, they were only invented because of those Agile teams. Even if you took away my refactoring tools and my unit test frameworks, I'd still be releasing early and often; my productivity would just be lower.
Wishful thinking, perhaps? You can never make any change completely fearlessly in most projects. Unit tests can do a lot to help increase your confidence and catch bugs early, but they are not a substitute for knowing what you're doing and understanding its implications, and neither are they foolproof.
Well, I did also say acceptance tests, which I think are also very valuable. I never suggested that they were a substitute for knowing what you're doing. It's true that they aren't foolproof; maybe it's just me, but I discourage hiring fools.
For one thing, it's impossible to get 100% test coverage for most projects. If you don't have full coverage, you can always break something in a gap.
This is true. From talking to people who do insurance company work, the kind of bug rates you can get get from doing unit and acceptance testing are already worlds better than what they are used to, and it may be enough for their environment. If not, there are other practices to do. I said they would be the first thing I did, not the only thing.
For another thing, if you have a few thousand lines of code and you're worried enough about bugs to write a few thousand more lines of unit tests, how can you possibily be confident that the extra few thousand lines are themselves bug-free and testing what you think you're testing?
Personally, I would be confident because I wrote them using test-driven development and pair programming on a team that uses collective code ownership, so all the code had been reviewed throughly. Also, because we would build along with them end-to-end acceptance tests that were defined by product experts. And were I cleaning up a legacy code base, I would check code coverage both the basic way and through a tool that randomly mutates code and looks for test failures, as well as through manual inspection.
That doesn't mean that I'd expect this to be perfect. Nothing is. But with that kind of coverage and related supporting practices, I'd expect bug-in-production rates to be between one per developer-month and one per month. That's been my previous experience, and that's more than good enough for most teams. If it weren't, I'd do more.
How does this work in regulated industries like insurance where changes affecting pricing and eligibility require filing updates to the manual with each state's Department of Insurance?
Good question. Maybe somebody who does that kind of work can speak up, but here's my take:
My first move would be to put a bunch of unit and acceptance tests around pricing and eligibility code. If we know we can't accidentally trigger a regulatory refiling, then we could change the system in other ways fearlessly.
Once you know you can't break things accidentally, then it seems like you could throw the question back in the laps of the guys in suits. If they request a change that requires re-filing everything, then you tell them so. If they want it, that's great. If not, that's also great.
I guess it's safe to assume that the internal website isn't subject to SOX compliance requirements...
It depends on your SOX auditor, but if you've got a sane one, there's no reason you can't follow an agile process with, at most, minor modifications from what you'd see in an Extreme Programming book.
And it's good to remember that nothing of this has anything to do with Web 2.0 :)
I think the one tie is that before Web 2.0 a lot of people would hear about these approaches and say "unpossible!" Now that you can point to plenty of successes that work like this, people can't be as casually dismissive.
Your evidence is one 9-year-old article by some low-rent technology journalist about the giant oil-company/hot-fusion conspiracy against fusion? Please.
Right now there is more investment in any and every half-baked energy plan than there has ever been. The Economist magazine just did a 14-page special section listing all of the exciting options. If the conditions were ever such that large companies could suppress promising energy research, they have since passed.
user involvement is still handled by marketing and trickles down to R&D at a slowly and ambiguously. I see this as our weak point.
You're right; that is a common mistake.
In my view, Agile development is all about making feedback loops effective and fast. Even if you're releasing software regularly, that isn't enough; you have to see how it's affecting the users. Maybe that means developers are directly involved and maybe not, but you should certainly be sitting within easy conversational distance of somebody who does spend a lot of time studying your users.
In short, you're right: going faster doesn't help if you don't look where it's getting you and steer accordingly.
I'm not impressed with the "perpetual beta" and "using your users for Q/A" concept. Remember, the users can leave.
The upside is that if you do it right, they're more involved than ever. Google was in beta for years, as was Flickr. I was fine with that; being an early adopter and watching the product evolve was exciting, especially when they did something in response to user feedback.
I think this has more to do with the free man-hours devs get from users testing amd troubleshooting their products, then anything else, really.
That's definitely one source of benefit. And generally, people are happy to give it. There are a variety of beta-quality products I use, and am glad to give early feedback because it helps me get a product more in line with what I want. When I don't have the time to deal with beta-quality stuff, I pay up for a finished product.
From a developer perspective, I love this, too. You never really know what people are going to do with something until you give it to them. If you're Microsoft, you'll sit there piling up several years' worth of guesses, and then find out all at once how you did. I think it's much safer and saner to release early and often, so you can correct your small problems before they become big ones. If I had to pay users to do that, I probably would, but so far, there seem to be plenty of free ones.
And with all of these little incremental updates, how do you not kick all of your users off of the system repeatedly? Sit around and wait for everyone to log off?
Depends on your technology, but by and large you build things in such a way that you can shift load around without people noticing. In web-land, that's generally done with load balancer tricks when upgrading the front end, and a smart service layer when upgrading back-end apps.
I hate the bombardment of updates I have to run now. Windows, Adobe, some install manager, Adobe, Java, Abobe... You get the idea.
Well, I'd more call this "Agile done stupid". It's possible to make automatic update processes pretty much seamless from the user's perspective. That some companies aren't good at paying attention to what the user actually wants is a problem that predates Agile methods.
So companies that like to sell software based on 12-18 month releases will never move to a true "agile" development...
I don't think that's necessarily the case. The excellent Java IDE has release and early-access versions. The release version costs money and has a new version every year or so. The early-access version is free, beta quality, comes out frequently, and expires every month or so. Users can pick whether they want stability or features more. This has been working well for them for the last few years, and could see it working well for a lot of people.
For instance, my company develops health care diagnostic solutions, some of which are heavily regulated. While many of our tools and products could highly benefit from this design approach, federal regulations simply make it an impossibility.
You'd be surprised. There are a number of medical device people who are active in the Agile world. Yes, you can't push new code to somebody's pacemaker every morning, so there are some limits. But they are definitely applying Agile lessons even in heavily regulated spaces, so it's worth checking them out.
This has nothing to do with Web 2.0 and is instead similar to the Agile software development process.
Yes and no. It's true that the Agile people had this pretty well figured out well before the Web 2.0 wave.
However, part of the reason that Agile methods have so much uptake is that the Web 2.0 companies are releasing early and often, both showing that it can be done and forcing their competitors to step up the pace. I also give some credit to the Rails people, who built a framework that supports key Agile practices like unit testing and short feedback loops.
I wish all this was true. Incremental and fast and includes clients. Sounds like a recipe for disaster to me. Sorry but I really have not seen development teams using such methods successfully.
Works for me. It requires supporting disciplines, though. In my view, that includes a well-meshed team, a very disciplined product management process, strong automated testing, a relentless devotion to code quality, and continual examination of your architectural choices.
It also works for plenty of other people. Flickr released every few hours, and they ended up selling for $20m after 18 months of work. YouTube releases once a week for interface changes and once a month for database changes, and they always have. At a billion views a day, I'd call them pretty successful.
I never understood these. What's wrong with typing 'make test' frequently? But yeah, "don't check in broken stuff into mainline" is good advice.
It's not one or the other; you do both. A CI server saves you from the people who forget to do that. And it saves you from screwing things up for other people when you forget to check in a file or have some weird environment difference on your own machine.
Without a CI server, either the fussiest person becomes the bad cop, yelling at the less careful and ending up resented. Or things just stay broken forever until the final push. With a CI server, the machine does the grumbling instantly, freeing the fussiest person to do real work. As somebody who is frequently the team fussbudget, I love not having to prod people all the time. And I love that the machine makes me live up to my own high standards.
Of course, I'd expect people to learn from each other, so they write more similar code over time.
We're on the same page here. The best teams I see definitely do end up evolving a common style and own the code collectively, so you really can't tell.
I phrased it the way I did, in terms of nice chats and eventual convergence, because the rock I'm trying to steer him around is the clash you get when people believe their personal stylistic preferences are inviolable laws of nature. Indulge that and you end up with code silos, mutual irritation, and lower productivity.
To work together as an effective team, they will need enough of a shared style that they are comfortable working in each other's code. Solving the points of difference now will make it much easier to add a third or fourth developer, and it will also ease the transition when one of them decides to move on.