Mandatory community service? Great, let's send a bunch of unmotivated kids to do stupid work. Hell, that kind of shit would have been a nightmare for me at that age when I had massive social anxiety and was extremely uncomfortable in such situations.
My junior high school had a volunteering requirement. I served it as a lab tech / support guy for a local junior college. Until you mentioned this, I hadn't thought about it in years, but it definitely made a big and very positive difference in my life.
At the time, I really hated school, as I was both dorky and socially anxious. But the time volunteering was great for me. People respected me for knowing how to solve their problems. I got to learn a lot. And I think it was where I first appreciated how much trouble and confusion badly made software causes.
Of course, people will come out of the woodwork to say how because it's something that people "should" do (because helping people IS nice, after all...) that Obama should MAKE you do it. Please, someone explain to me how you justify that leap.
Sure. That's pretty easy. It's an incredibly effective way for people to learn things that they can't learn in the classroom. We spend oceans of money giving people book-learning about our culture, our society, and our government. But purely academic knowledge is much more useful and much less likely to fade when it's backed up with real experience.
Plus, given that one of the functions of our educational system is to prepare people to deal with the real world, asking them to actually do that a couple hours a week seems reasonable. As citizens, we are expected to run our communities. You can't effectively run something you don't understand.
Why couldn't they think like that before the election? It is sad, truly sad.
Some years back, when I started to lose it on top, I shaved off my pony tail, and stayed a chrome-dome for a year or so.
A couple of months in, I was talking with pals over beers, and told them that the weirdest thing about it was that strangers treated me differently. Nervous looks in the grocery store line. Uncomfortable pauses when chatting with people on the bus. Crossing the street so they didn't have to pass me on the sidewalk. One of those friends, whose parents are African immigrants, and who is one of the most affable people I know, said, "Yeah, now you know how it is to be black."
I didn't, of course, not really. How could I? But I could see that if you spent your whole life with people treating you as different, lesser, or scary on a daily basis, it would tend to color your outlook. And what I'm sure of is that most white people have absolutely zero understanding of what it's like to not have the instant boost in regard that they get just from being white.
Heh. I agree mostly. But I think people can easily get carried away if they don't think that line of reasoning through.
Fairly exercising any power over others is difficult, especially power involving force. So except for circumstances where physical force is immediately necessary to prevent grievous harm, I think the necessary deliberation and due process is beyond that which a single mortal can usually achieve.
Ergo, I consider my delegation of the use of force to my government basically irrevocable, despite all the inefficiencies involved there. Because otherwise, I'd sometimes have a hard time persuading myself that certain douchebags who needed a pounding shouldn't get it right then from me personally.
Better yet, find a way to make this work part of a thesis for one of these students... then you might not have to pay them at all.:)
I can understand the appeal of this, but it is probably a terrible idea.
There is an almost universal problem with CS students that gets worse the longer they are students. Because classes end soon and school ends eventually, they have little or no experience maintaining code. They thus don't know how to write for maintainability, and instead have a host of tricks for quick solutions.
Because students are always throwing away their code bases, short-term wins are great, and the long-term costs don't matter. But for professional software development, the opposite applies; almost any successful code base lives forever. Short-term wins are minor bonuses, and long-term costs dominate massively. When hiring people fresh out of school, I always make sure they work closely with grizzled veterans, as they have a lot of habits to unlearn.
Since the original poster wants reusability, he should hire somebody with enough professional experience to know what they're doing. I'd say at least 2x the time he'd like the code base to last without a major rewrite.
A second option is to look at rentacoder.com - put out a request, your budget, and include the requirement about being F/OSS software. Get your bids, make a choice, etc.
This is a reasonable option for throw-away software, but the original poster is a non-programmer looking for something solid and reusable, qualities he can't personally judge.
For any sort of fixed-price contracting, the incentive for the contractor is to develop something minimally compliant and then flee. Reusable code requires discipline and polish. Because reuse always comes later, and because it's hard to measure or prove shoddy construction, odds of getting a christmas-paper-wrapped turd are high.
I personally haven't tried rent-a-coder, so maybe they are miraculously different there. But I have a lot of experience with outsourced development, generally as the guy who has to clean up the mess. 100% of the fixed-price jobs I've seen were junk, and probably 85% of the time-and-materials jobs were also throw-aways, where the code base had so much technical debt that it would be cheaper to throw away and rebuild than to try to reuse.
I think his better bet is to find some local former grad student turned developer and hire him to work on the stuff intermittently but indefinitely. If the developer believes that he will have to live with the code for the foreseeable future, and in particular if he believes he'll be the one reusing it, he'll have the incentive to do a good job.
Every good work of software starts by scratching a developer's personal itch.
That's true, but you're not interpreting it broadly enough.
Sure, if he finds a developer who wants this software already, then that's great. But there are other ways to get people personally engaged in a project.
One is to make sure it involves technical challenges the developer finds interesting. E.g., a good Cocoa developer who's wanted to use Core Data but hasn't. Or, assuming that statistics play a part here, a developer who has always wanted to learn about that. That's not enough on its own, but it's a good start.
Next, find ways to get the developer engaged in the domain. A developer with an interest in this kind of science would be great. A lot of good developers started out studying something else, so it's possible he could find somebody with graduate training in his domain.
Third, connect the developer in a personal way to the people who need the software. If this is lab software, then just pay him to spend a week working in the lab with the future users. Have development happen as close as possible to the users. Maybe in the same room, and certainly close enough that they share the same break areas and would naturally go to lunch together.
Fourth, get a good feedback loop going. Show demos every week or two to actual users. As soon as possible, get an alpha version actually in use, and release updates every week or two. Get everybody together weekly over coffee to talk about how it's working. And occasionally get people together over beers to talk about the bigger picture.
Do all these things, and the developer's personal itch is to make something great that satisfies people he has come to care about, people working in a context he understands intuitively.
Why being single = a bad thing, I don't think I'll totally understand.
Because most people don't like it. And because without that attitude, we might not be here.
The biggest thing every person on this planet has in common is an unbroken line of ancestors going back millions of years. I don't want to give away too much here, but there's a strong correlation between relationships and babies. Being more happy in a relationship than out of one is, from the perspective of your genes, a survival trait.
Sure, from your individual perspective, being single might be fine. But you aren't in charge of building human brains and bodies; your genes are. Until that changes, the vast majority of humans will always have the urge to pair up.
I too remove obnoxious advertising campaigns that abuse my neighborhood.
I believe neighborhood watches are supposed to contact the appropriate authorities, not resort to vigilantism. In your case, please call your municipal sanitation department.
I'm not sure where you're at, but I'm in the US. Here, it's government of, by, and for the people. I may call the government where the job is too big or too specialized for me, but I always start with the assumption that neighborhood problems are for me and my neighbors to solve. Don't you?
No offense, but if your ISP's only upstream is Cogent, you need a better ISP. There is a reason that Cogent is much, much cheaper than the first-rate providers. I know a number of sysadmins that use Cogent, some with gigabit connections. But I don't know anybody serious who depends on them.
If you've made software long enough, you can look at software and tell something about the people who make it, and my impression from the early Twiki versions was that the people behind it just couldn't think about things from an end-user perspective. For an inherently social app, that's bizarre.
Further, from the number of bugs and security holes, they clearly weren't very good coders.
This move seems like it falls in the "once a jerk, always a jerk" category.
You cannot change the function to use UTF-8 internally without also changing all callers of this function. [...] Sure, they are small changes, but it takes time to find all the places where the change is needed, and they are scattered all over the code base.
Well, maybe you can't. I don't know enough about your specific case, but I've got a whole bag of tricks for working incrementally on things like this.
Often to me things that "have to" be changed everywhere at once are signs of poor encapsulation. If I'm changing the internal encoding of some data structure and I have to touch code all over the place, then that's a sign that it's not really internal, so I need to first pull together that code. Duplication is my sworn enemy, and I work in the style often called Once And Only Once (OOAO) or Don't Repeat Yourself (DRY).
I don't quite get your situation, but this sounds like poor encapsulation of the string. That's not uncommon; a lot of code out there confuses char arrays and byte arrays and strings. But I'd solve the confusion to refactoring to use real string objects first, which can indeed be done incrementally. Then the code I actually have to change is not spread out all over, it's in one place.
When averything you are doing in your branch are small (one-line) changes like this, you don't have a big problem a month later when you do the merge.
Depends on your project. Releasing new features weekly and a team refactoring aggressively means that branching for an entire month would mean a giant, giant painful merge at the end. So it might be ok in your environment, but it'd be awful in mine.
What do you do when the customer rep says: "This time is extremely critical for us. It will be very expensive for us if your changes reveal any bugs in our code or our business processes. Therefore we want no new features, no enhancements, and no bugfixes except this one."
In the short term, I'd always say yes. But in the longer term, I'd look at why they don't trust that our stuff would just work. If it's because there really is a substantial risk of a significant bug, I'd fix that. Once quality is sorted, I'd figure out how to build more trust.
I know there are some kinds of software where you don't hear this kind of thing. I worked on a desktop app where we sometimes rolled out major new features without any notice and sat at our desks with big grins waiting for the excited calls of gratitude to come in:-)
Yes, that is indeed delicious.
That might be a pretty rare scenario, but I imagine that temporary exclusivity is common practice when a customer contributes money or expertise to the development a new feature.
Yeah, definitely. One team I'm working with produces software that they sell as a service, but each client pays for different features, and has different customizations. They manage that all through allowing for configuration and localization. I've seen others use content management systems. If that got complicated enough, it would be reasonable to put all those config files and special templates in version control, but I would treat those as separate projects, and not clutter my main code base with them, as the customizations and configurations have very different needs and moderately different lifecycles than the main code base.
Yes, I understand you haven't heard of it and can't imagine it. That's why we're having such a long discussion here.
The agile approach works best when agile principles infect an entire organization. It can affect product management, marketing, budgeting, rollouts, support, and yes, configuration management.
What is sounds like is you have very poor RC/CM process and have developed a development process to hide that fact. If it works for you, that's fine, but it's still inferior to RC/CM best practises. Does the earth stop spinning? No. Do you have a lot to learn? Absolutely.
Yes, I've heard that same line from pretty much every specialist perspective. "Sure, agile's fine for development, but you can't possibly do good X that way. It's impossible!" Where X is visual design, interaction design, product management, software release, QA testing, usability, project planning, project budgeting, and product portfolio management. But guess what, people are making it work, and have spent the last decade confounding naysayers like yourself.
Note that you haven't pointed out any particular practical, real-world consequence of, say, an Extreme Programming team not following your precious best practices. You're arguing dogma, not results.
I'm happy to put pretty much any specialist book people recommend to me on my reading list; I've got shelves and shelves of books on various aspects of software development. If I can find some practical benefit in some particular practice from any field, I'll adopt it, and I'm continually experimenting with new options. I'm done with other people's dogma, though, especially from random people and/or dogs on Slashdot.
I stand by my statement that started this: 90% of the branching I see is to compensate for social or technical brokenness. If you solve those root causes, not only do you avoid the need for the branch-and-merge shenanigans, you also solve the root problem. Getting bug rates to approach zero, for example, has all sorts benefits beyond meaning you don't have to screw around with stable branches. Benefits like reliable schedules and going home on time.
Did you happen to note that pretty consistently, everyone told you the same thing? There is a reason for that.
You're seriously telling me to change my process because some people on Slashdot got upset at a deliberately inflammatory post? Heh. That's precious.
I've been doing Extreme Programming and other agile methods for many years now. From the beginning, some people said it was impossible and broken. Like you, the people who said it the loudest were a) steeped in old methods, and b) mainly ignorant of the new ones.
I might have been put off by that years ago, but guess what! The new methods worked better for me. Your sour theories and dogmatic arguments are not as persuasive to me as my successes.
This year the agile conference was 17x larger than when I first attended, and surveys show major agile uptake. Agile methods may be in a majority of organizations by now. If you think "everybody says so" is a valid argument, then you're on the wrong end of it.
I'm loosely familiar with both. Both are development processes. A development process is not a replacement for RC/CM process.
I wouldn't say it's a replacement, but the they're not as separable as you seem to suggest. The right RC/CM choices are driven by development needs and how you handle business needs. Agile methods radically alter both.
If I am releasing weekly, if my developers are all in a room, if our bug rates are negligibly low, and if we're committing every few hours, then 99% of the time, we all just commit to trunk. It is not a problem. (That 1% is when somebody really needs an in-production change that can't wait a few days, in which case we find our last release tag, branch, and do our thing.)
As to the business side, our practices are equally lean. We always have business people in the room empowered to make decisions. Every Monday morning, we decide what we'll do for the week. And as we build, we work closely together. That makes traceability easy. Since, like a lot of people, we build apps that run on servers we control, managing deployed software is easy. Because releases are so frequent, our release process is heavily automated.
In sum: we release weekly and have for years, our bug rates are very low, the business people get what they want when they want it, our users are happy, and business is great. Oh, and developers go home on time every day. If that's a sign of failed traditional RC/CM, then please, tell me how to fail harder at it.
Yeah, that's a horror. In the agile software development world, there's a saying: either change your organization, or change your organization. If I worked there, I'd call it an obvious opportunity to apply that.:-)
I'm probably comfortable with it because my colleagues and I are merciless refatorers. Dead code doesn't last long, as it tends to stand out in the code base. Since we trust we'll clean it up, we're not afraid of making a little mess now and again.
Could be. For me, the costs turn out to be much lower. But given that my teams are doing pair programming, weekly releases, and test-driven development, with >95% unit test coverage and high levels of acceptance test coverage, I could see a lot of things like that would be different for us.
I guess you could call them hacks. But if we're going to talk like that, then I'd be happy to say that branching just to isolate you from what your team is up to is putting your hands over your ears and pretending that you're in your own little bubble. It's ignoring reality. La la la!
Hacks or not, they can work very well. In my view, as long as you're disciplined about it, there's no real problem with having modest amounts of in-progress work committed. It lets other developer know what's going on. It lets you test the feature as early as possible and in a way that's as real as possible. If you've got to deal with reality sometime, I'd say do it now.
Personally, I tend to do those things either incrementally or automatedly, so they can be checked in frequently. I personally prefer that; once I got good at it, it saved me the hassle of trying to keep up with other people's conflicting changes.
If you have the personal charisma where the benefits of GIT outweigh the risks, then go for it. I don't. GIT only works when you have a strong cult of personality leading a group.
That's a great point.
One of the things a lot of people in this thread seem to struggle with is how the social structure affects your software needs, and how your software can encourage or discourage particular behaviors. Glad to see somebody else gets it!
My point is that people should stop doing that. In a team context, the more divergence you have, the harder it is to understand, and therefore the harder it is to resolve.
The teams I work with commit every few hours, so they don't have much need for branching, local or central.
You're part way there. I agree you should commit before going home. I just think you should work in such a way that before going home you can commit to trunk, or however it is that you publish the change to everybody.
Sure. I've worked on systems with hundreds of other active developers. These days I focus most of my effort on smaller teams, as the fall-off in productivity is incredible. For things that are too big for one team, I favor a team-of-teams approach, with distributed responsibility.
but really, it is unlikely at best to make sure that a given commit (or "check-in") is entirely stable
I believe that for most software, you can solve this through fully automated testing. And further, that investment in automated testing is usually much cheaper over the long haul than manual testing.
I just worked with a team that took a mission-critical single-box application and made it fully distributed. It took them quite a while, as it was a complicated app, but they did it by committing every few hours and releasing every week or so. There was no significant increase in bugs compared with their normal feature development, which followed a similar checkin and release schedule. And that's good, because by "mission critical," in this case I mean it's the entire purpose of the company, and where all the money comes in.
You do that the same way you eat an elephant: one bite at a time.
Slashdot Mirror
Mandatory community service? Great, let's send a bunch of unmotivated kids to do stupid work. Hell, that kind of shit would have been a nightmare for me at that age when I had massive social anxiety and was extremely uncomfortable in such situations.
My junior high school had a volunteering requirement. I served it as a lab tech / support guy for a local junior college. Until you mentioned this, I hadn't thought about it in years, but it definitely made a big and very positive difference in my life.
At the time, I really hated school, as I was both dorky and socially anxious. But the time volunteering was great for me. People respected me for knowing how to solve their problems. I got to learn a lot. And I think it was where I first appreciated how much trouble and confusion badly made software causes.
Of course, people will come out of the woodwork to say how because it's something that people "should" do (because helping people IS nice, after all...) that Obama should MAKE you do it. Please, someone explain to me how you justify that leap.
Sure. That's pretty easy. It's an incredibly effective way for people to learn things that they can't learn in the classroom. We spend oceans of money giving people book-learning about our culture, our society, and our government. But purely academic knowledge is much more useful and much less likely to fade when it's backed up with real experience.
Plus, given that one of the functions of our educational system is to prepare people to deal with the real world, asking them to actually do that a couple hours a week seems reasonable. As citizens, we are expected to run our communities. You can't effectively run something you don't understand.
Why couldn't they think like that before the election? It is sad, truly sad.
Some years back, when I started to lose it on top, I shaved off my pony tail, and stayed a chrome-dome for a year or so.
A couple of months in, I was talking with pals over beers, and told them that the weirdest thing about it was that strangers treated me differently. Nervous looks in the grocery store line. Uncomfortable pauses when chatting with people on the bus. Crossing the street so they didn't have to pass me on the sidewalk. One of those friends, whose parents are African immigrants, and who is one of the most affable people I know, said, "Yeah, now you know how it is to be black."
I didn't, of course, not really. How could I? But I could see that if you spent your whole life with people treating you as different, lesser, or scary on a daily basis, it would tend to color your outlook. And what I'm sure of is that most white people have absolutely zero understanding of what it's like to not have the instant boost in regard that they get just from being white.
Heh. I agree mostly. But I think people can easily get carried away if they don't think that line of reasoning through.
Fairly exercising any power over others is difficult, especially power involving force. So except for circumstances where physical force is immediately necessary to prevent grievous harm, I think the necessary deliberation and due process is beyond that which a single mortal can usually achieve.
Ergo, I consider my delegation of the use of force to my government basically irrevocable, despite all the inefficiencies involved there. Because otherwise, I'd sometimes have a hard time persuading myself that certain douchebags who needed a pounding shouldn't get it right then from me personally.
Better yet, find a way to make this work part of a thesis for one of these students... then you might not have to pay them at all. :)
I can understand the appeal of this, but it is probably a terrible idea.
There is an almost universal problem with CS students that gets worse the longer they are students. Because classes end soon and school ends eventually, they have little or no experience maintaining code. They thus don't know how to write for maintainability, and instead have a host of tricks for quick solutions.
Because students are always throwing away their code bases, short-term wins are great, and the long-term costs don't matter. But for professional software development, the opposite applies; almost any successful code base lives forever. Short-term wins are minor bonuses, and long-term costs dominate massively. When hiring people fresh out of school, I always make sure they work closely with grizzled veterans, as they have a lot of habits to unlearn.
Since the original poster wants reusability, he should hire somebody with enough professional experience to know what they're doing. I'd say at least 2x the time he'd like the code base to last without a major rewrite.
A second option is to look at rentacoder.com - put out a request, your budget, and include the requirement about being F/OSS software. Get your bids, make a choice, etc.
This is a reasonable option for throw-away software, but the original poster is a non-programmer looking for something solid and reusable, qualities he can't personally judge.
For any sort of fixed-price contracting, the incentive for the contractor is to develop something minimally compliant and then flee. Reusable code requires discipline and polish. Because reuse always comes later, and because it's hard to measure or prove shoddy construction, odds of getting a christmas-paper-wrapped turd are high.
I personally haven't tried rent-a-coder, so maybe they are miraculously different there. But I have a lot of experience with outsourced development, generally as the guy who has to clean up the mess. 100% of the fixed-price jobs I've seen were junk, and probably 85% of the time-and-materials jobs were also throw-aways, where the code base had so much technical debt that it would be cheaper to throw away and rebuild than to try to reuse.
I think his better bet is to find some local former grad student turned developer and hire him to work on the stuff intermittently but indefinitely. If the developer believes that he will have to live with the code for the foreseeable future, and in particular if he believes he'll be the one reusing it, he'll have the incentive to do a good job.
Every good work of software starts by scratching a developer's personal itch.
That's true, but you're not interpreting it broadly enough.
Sure, if he finds a developer who wants this software already, then that's great. But there are other ways to get people personally engaged in a project.
One is to make sure it involves technical challenges the developer finds interesting. E.g., a good Cocoa developer who's wanted to use Core Data but hasn't. Or, assuming that statistics play a part here, a developer who has always wanted to learn about that. That's not enough on its own, but it's a good start.
Next, find ways to get the developer engaged in the domain. A developer with an interest in this kind of science would be great. A lot of good developers started out studying something else, so it's possible he could find somebody with graduate training in his domain.
Third, connect the developer in a personal way to the people who need the software. If this is lab software, then just pay him to spend a week working in the lab with the future users. Have development happen as close as possible to the users. Maybe in the same room, and certainly close enough that they share the same break areas and would naturally go to lunch together.
Fourth, get a good feedback loop going. Show demos every week or two to actual users. As soon as possible, get an alpha version actually in use, and release updates every week or two. Get everybody together weekly over coffee to talk about how it's working. And occasionally get people together over beers to talk about the bigger picture.
Do all these things, and the developer's personal itch is to make something great that satisfies people he has come to care about, people working in a context he understands intuitively.
Why being single = a bad thing, I don't think I'll totally understand.
Because most people don't like it. And because without that attitude, we might not be here.
The biggest thing every person on this planet has in common is an unbroken line of ancestors going back millions of years. I don't want to give away too much here, but there's a strong correlation between relationships and babies. Being more happy in a relationship than out of one is, from the perspective of your genes, a survival trait.
Sure, from your individual perspective, being single might be fine. But you aren't in charge of building human brains and bodies; your genes are. Until that changes, the vast majority of humans will always have the urge to pair up.
I too remove obnoxious advertising campaigns that abuse my neighborhood.
I believe neighborhood watches are supposed to contact the appropriate authorities, not resort to vigilantism. In your case, please call your municipal sanitation department.
I'm not sure where you're at, but I'm in the US. Here, it's government of, by, and for the people. I may call the government where the job is too big or too specialized for me, but I always start with the assumption that neighborhood problems are for me and my neighbors to solve. Don't you?
No offense, but if your ISP's only upstream is Cogent, you need a better ISP. There is a reason that Cogent is much, much cheaper than the first-rate providers. I know a number of sysadmins that use Cogent, some with gigabit connections. But I don't know anybody serious who depends on them.
Yeah, I agree.
If you've made software long enough, you can look at software and tell something about the people who make it, and my impression from the early Twiki versions was that the people behind it just couldn't think about things from an end-user perspective. For an inherently social app, that's bizarre.
Further, from the number of bugs and security holes, they clearly weren't very good coders.
This move seems like it falls in the "once a jerk, always a jerk" category.
You cannot change the function to use UTF-8 internally without also changing all callers of this function. [...] Sure, they are small changes, but it takes time to find all the places where the change is needed, and they are scattered all over the code base.
Well, maybe you can't. I don't know enough about your specific case, but I've got a whole bag of tricks for working incrementally on things like this.
Often to me things that "have to" be changed everywhere at once are signs of poor encapsulation. If I'm changing the internal encoding of some data structure and I have to touch code all over the place, then that's a sign that it's not really internal, so I need to first pull together that code. Duplication is my sworn enemy, and I work in the style often called Once And Only Once (OOAO) or Don't Repeat Yourself (DRY).
I don't quite get your situation, but this sounds like poor encapsulation of the string. That's not uncommon; a lot of code out there confuses char arrays and byte arrays and strings. But I'd solve the confusion to refactoring to use real string objects first, which can indeed be done incrementally. Then the code I actually have to change is not spread out all over, it's in one place.
When averything you are doing in your branch are small (one-line) changes like this, you don't have a big problem a month later when you do the merge.
Depends on your project. Releasing new features weekly and a team refactoring aggressively means that branching for an entire month would mean a giant, giant painful merge at the end. So it might be ok in your environment, but it'd be awful in mine.
What do you do when the customer rep says: "This time is extremely critical for us. It will be very expensive for us if your changes reveal any bugs in our code or our business processes. Therefore we want no new features, no enhancements, and no bugfixes except this one."
In the short term, I'd always say yes. But in the longer term, I'd look at why they don't trust that our stuff would just work. If it's because there really is a substantial risk of a significant bug, I'd fix that. Once quality is sorted, I'd figure out how to build more trust.
I know there are some kinds of software where you don't hear this kind of thing. I worked on a desktop app where we sometimes rolled out major new features without any notice and sat at our desks with big grins waiting for the excited calls of gratitude to come in :-)
Yes, that is indeed delicious.
That might be a pretty rare scenario, but I imagine that temporary exclusivity is common practice when a customer contributes money or expertise to the development a new feature.
Yeah, definitely. One team I'm working with produces software that they sell as a service, but each client pays for different features, and has different customizations. They manage that all through allowing for configuration and localization. I've seen others use content management systems. If that got complicated enough, it would be reasonable to put all those config files and special templates in version control, but I would treat those as separate projects, and not clutter my main code base with them, as the customizations and configurations have very different needs and moderately different lifecycles than the main code base.
Yes, I understand you haven't heard of it and can't imagine it. That's why we're having such a long discussion here.
The agile approach works best when agile principles infect an entire organization. It can affect product management, marketing, budgeting, rollouts, support, and yes, configuration management.
What is sounds like is you have very poor RC/CM process and have developed a development process to hide that fact. If it works for you, that's fine, but it's still inferior to RC/CM best practises. Does the earth stop spinning? No. Do you have a lot to learn? Absolutely.
Yes, I've heard that same line from pretty much every specialist perspective. "Sure, agile's fine for development, but you can't possibly do good X that way. It's impossible!" Where X is visual design, interaction design, product management, software release, QA testing, usability, project planning, project budgeting, and product portfolio management. But guess what, people are making it work, and have spent the last decade confounding naysayers like yourself.
Note that you haven't pointed out any particular practical, real-world consequence of, say, an Extreme Programming team not following your precious best practices. You're arguing dogma, not results.
I'm happy to put pretty much any specialist book people recommend to me on my reading list; I've got shelves and shelves of books on various aspects of software development. If I can find some practical benefit in some particular practice from any field, I'll adopt it, and I'm continually experimenting with new options. I'm done with other people's dogma, though, especially from random people and/or dogs on Slashdot.
I stand by my statement that started this: 90% of the branching I see is to compensate for social or technical brokenness. If you solve those root causes, not only do you avoid the need for the branch-and-merge shenanigans, you also solve the root problem. Getting bug rates to approach zero, for example, has all sorts benefits beyond meaning you don't have to screw around with stable branches. Benefits like reliable schedules and going home on time.
Did you happen to note that pretty consistently, everyone told you the same thing? There is a reason for that.
You're seriously telling me to change my process because some people on Slashdot got upset at a deliberately inflammatory post? Heh. That's precious.
I've been doing Extreme Programming and other agile methods for many years now. From the beginning, some people said it was impossible and broken. Like you, the people who said it the loudest were a) steeped in old methods, and b) mainly ignorant of the new ones.
I might have been put off by that years ago, but guess what! The new methods worked better for me. Your sour theories and dogmatic arguments are not as persuasive to me as my successes.
This year the agile conference was 17x larger than when I first attended, and surveys show major agile uptake. Agile methods may be in a majority of organizations by now. If you think "everybody says so" is a valid argument, then you're on the wrong end of it.
I'm loosely familiar with both. Both are development processes. A development process is not a replacement for RC/CM process.
I wouldn't say it's a replacement, but the they're not as separable as you seem to suggest. The right RC/CM choices are driven by development needs and how you handle business needs. Agile methods radically alter both.
If I am releasing weekly, if my developers are all in a room, if our bug rates are negligibly low, and if we're committing every few hours, then 99% of the time, we all just commit to trunk. It is not a problem. (That 1% is when somebody really needs an in-production change that can't wait a few days, in which case we find our last release tag, branch, and do our thing.)
As to the business side, our practices are equally lean. We always have business people in the room empowered to make decisions. Every Monday morning, we decide what we'll do for the week. And as we build, we work closely together. That makes traceability easy. Since, like a lot of people, we build apps that run on servers we control, managing deployed software is easy. Because releases are so frequent, our release process is heavily automated.
In sum: we release weekly and have for years, our bug rates are very low, the business people get what they want when they want it, our users are happy, and business is great. Oh, and developers go home on time every day. If that's a sign of failed traditional RC/CM, then please, tell me how to fail harder at it.
Yeah, that's a horror. In the agile software development world, there's a saying: either change your organization, or change your organization. If I worked there, I'd call it an obvious opportunity to apply that. :-)
I'm probably comfortable with it because my colleagues and I are merciless refatorers. Dead code doesn't last long, as it tends to stand out in the code base. Since we trust we'll clean it up, we're not afraid of making a little mess now and again.
Heh. That is entirely the truth. :-)
Could be. For me, the costs turn out to be much lower. But given that my teams are doing pair programming, weekly releases, and test-driven development, with >95% unit test coverage and high levels of acceptance test coverage, I could see a lot of things like that would be different for us.
First, all of these methods are hacks.
I guess you could call them hacks. But if we're going to talk like that, then I'd be happy to say that branching just to isolate you from what your team is up to is putting your hands over your ears and pretending that you're in your own little bubble. It's ignoring reality. La la la!
Hacks or not, they can work very well. In my view, as long as you're disciplined about it, there's no real problem with having modest amounts of in-progress work committed. It lets other developer know what's going on. It lets you test the feature as early as possible and in a way that's as real as possible. If you've got to deal with reality sometime, I'd say do it now.
Personally, I tend to do those things either incrementally or automatedly, so they can be checked in frequently. I personally prefer that; once I got good at it, it saved me the hassle of trying to keep up with other people's conflicting changes.
If you have the personal charisma where the benefits of GIT outweigh the risks, then go for it. I don't. GIT only works when you have a strong cult of personality leading a group.
That's a great point.
One of the things a lot of people in this thread seem to struggle with is how the social structure affects your software needs, and how your software can encourage or discourage particular behaviors. Glad to see somebody else gets it!
Sorry I was confusing; I understand that.
My point is that people should stop doing that. In a team context, the more divergence you have, the harder it is to understand, and therefore the harder it is to resolve.
The teams I work with commit every few hours, so they don't have much need for branching, local or central.
You're part way there. I agree you should commit before going home. I just think you should work in such a way that before going home you can commit to trunk, or however it is that you publish the change to everybody.
Have you ever worked on a large software project?
Sure. I've worked on systems with hundreds of other active developers. These days I focus most of my effort on smaller teams, as the fall-off in productivity is incredible. For things that are too big for one team, I favor a team-of-teams approach, with distributed responsibility.
but really, it is unlikely at best to make sure that a given commit (or "check-in") is entirely stable
I believe that for most software, you can solve this through fully automated testing. And further, that investment in automated testing is usually much cheaper over the long haul than manual testing.
I just worked with a team that took a mission-critical single-box application and made it fully distributed. It took them quite a while, as it was a complicated app, but they did it by committing every few hours and releasing every week or so. There was no significant increase in bugs compared with their normal feature development, which followed a similar checkin and release schedule. And that's good, because by "mission critical," in this case I mean it's the entire purpose of the company, and where all the money comes in.
You do that the same way you eat an elephant: one bite at a time.