Actually.... QKS a Smalltalk vendor for the last 10 years, is working with Microsoft to produce SmallScript.
It is a new scripting based Smalltalk that runs (will run) on.NET. It is being developed "With" Microsoft in the same way that the Eiffel people are developing a version of Eiffel for.NET with Microsoft... IOW, it won't be a MS product, MS is just lending a hand to get Yet Another Language on their.NET platform.
This of course has nothing to do with the evilness of MS or the foolishness of.NET... or the lack of same.
You might not like this answer then. You didn't Refactor Mercilessly. Refactoring as a discreet development task is almost always a waste of time. Refactoring as a part of the process of adding or modifying a feature, as an intrinsic way of developing never is. The Refactoring you talk about is simply the rearranging the deck chairs on the Titanic. The Refactoring I talk about is the constant incremental improvement of code to assure that it always matches the current Best Vision of what the product/function should be.
"Simplest Thing That Can Possibly Work" -- "Almost nothing of what we do is simple"
Well, I work on enterprise applications, and I assure you, they are not simple either. Don't confuse E-Z with Simple. Simple is almost never E-Z. And it isn't about "as simple as possible" either! The simplest thing that can possibly work is often very hard, complex work. But it NEVER is more than is needed. It never attempts to guess what I will need tomorrow, only what I need today. Then, coupled with Refactoring as a intrinsic part of development, I am unafraid to add what is needed tomorrow, when I know what it is. Each identifiable increment is then the most simplest thing that can possibly work. The difficulty or ease in doing it has nothing to do with this idea.
"Embrace Change" -- "does not mean ignoring planning and re-use."
Mostly, I agree with your statements. I though have yet to see anyone accurately predict what the future will bring, and therefore, it is better to take a position of Embracing Change instead of pretending you can predict the future. Planning for now is one thing. Pretending one can accurately plan for the future is one of the "Big Lies" of our industry. One of the other "Big Lies" of our industry is being able to plan for Re-use. Constant incremental refactoring is Re-use in practice, there really is nothing else except the puffed up statements of supposed computer industry experts (an oxymoron at that!).
"Frozen at the end of Design" -- "You're Ignorant"
Well, whether I'm ignorant or not is not in dispute here. What is in dispute is if "Traditional" software design techniques imply feature sets are frozen at the end of design. I suggest you go back and read the traditional Waterfall process texts, and find where they imply where the features change within an iteration. I don't consider Spiral methods to be Traditional, but that could be a matter of opinion where we might disagree. Even so, in practice, none of these takes into account how to deliver on time, and still react immediately to new feature requests. XP's Planning Game, Stories, Engineering Tasks and Full Time Business Person does address this.
Question 1: XP Time increments are exact. At the end of every increment, there is a tangible deliverable, and there is no question that it is exactly what the Business User agrees with.
Question 2: Of course, all managers want to have time estimates. How its done changes, not the need.
Question 3: Yes. Except of course, it's not magic, its hard work.
You have made a fundamental mistake. You have equated "No Individual Code Ownership" with "No Code Ownership."
While this is a common mistake, it is not what XP professes. XP says there must be Communal Code Ownership. Instead of "Individual Code Ownership" where it's "My Code vs Their Code (And I'll do everything in my power to protect MY code from 'Them', those morons)", there is just "Our Code!"
The pride you speak of is cowboy pride. Pride in keeping my code working while all of the other morons screw up. It's the pride that leads to "Well, MY code worked!" How sad. Worse... it is frightfully pervasive.
There is another pride possible. "Our Code Works", and "I Contributed To Making Our Code Work", and "I Was Successful In Helping Our Project Be Wildly Successful!"
I have personally always found the former to be shallow and ultimately, unproductive, while latter to be the only truly satisfying form of pride I have ever experienced.
Haven't yet in 20 years in this business. I have time and again asked my Colleagues over the years if any one of them have seen one, but they haven't.
So I no longer believe they exist, any more than the Tooth Fairy, Hanukkah Harry, Compassionate Lawyers or Honorable Politicians.
That's why I support XP. It finally puts to rest the notion that what hasn't yet worked, should work, and will work, if we only somehow believe it harder... Maybe by clapping our hands together and chanting "I Believe In Detailed Specifications... I Believe In Detailed Specifications..." until Tinker Bell comes back to life.
Detailed Specifications are like UFOs. Some people want to believe they exist, and that someone out there has actually seen them. However while the evidence doesn't stand up to the light of day, it doesn't seem to diminish the large amount that is written about them, nor the hope that someday we'll prove they actually exist, despite the government cover-up.
It's too bad you don't consider work 'coding for fun.' It speaks volumes about the failure of the processes and procedures that pervade the industry. For me, its always fun. So much so, that I don't feel the want to hack at home much anymore. As a matter of fact, I tend to dislike it because I don't have anyone to work with. But then, I'm a consultant, and when I find a place that isn't fun, I just move on.
If you do not Refactor Mercilessly. If you do not have Unit Tests covering all code. If you do not pursue the Simplest Thing That Can Possibly Work. If you do not work in pairs. If you do not Embrace Change.
--AND--
If you think that todays Design Document will cover all of tomorrows problems. If you think the Design & Analysis Documents will exactly match the finished product. If you think the feature set is frozen at the end of Design. If you think you can accurately estimate the time for implementation before it starts.
--OR--
You can do it with XP, and realize it MUST work without one of those boring library design meetings. Because it hasn't worked yet, your way.
Isn't it interesting that all through our school years, we are told over and over that working WITH another is cheating. And what happens the first time we get out in the business world? We're told "We want team players!"
But we have no experience in doing that. So, as programmers, we talk the talk of "Team" and Tony What's-His-Name and sharing and empowerment, but the moment we start to work, we revert to the Cowboy ethic, which is, after all, the only thing we know.
The very idea of Pair Programming and Communal Code Ownership is so foreign to us as to not even make sense to us. It doesn't seem rational much less possible.
So we just say "It Doesn't Work", "It's Less Productive", "If Only We Did Right What We're Doing Now, We Wouldn't Be Talking About This Idiotic Fantasy"
And there in a nutshell is the problem. XP is an attempt to define a process where "YOU" are truly empowered, not just some lip service where in the end you just go back to your closed door office and pound the keyboard, Twinkie and Latte in hand.
"But Sharing Gets Me Nowhere!" you say in the quiet of your mind. "Power and career advancement does not come from sharing." True enough. In the "Real World" it comes from having knowledge and demonstrating ability that others do not have. This XP stuff all seems like some Utopian world where everyone knows the project that they're working on, can help anyone on their team with any part of the project, can be unafraid to attack a new or old part of the project that they've never seen before, to try new things all the time without worry that it will break something.
Yup. It's purely the things dreams are made of. Except... Except... It works. When all is said and done, and you do all of the practices, and you put your pride on the line that you will do the best for the PROJECT and the PROCESS as a whole instead of your small corner of the world, it works.
Let's get real. Most Code-Review is a waste of time. Hours and hours of person time is wasted in what seems like should work, but never has.
What usually happens is a bunch of people sit around in endless dreadful meetings, looking at lifeless code listings, making superfluous comments about style and imagined execution. They are as a whole, unable provide ANY meaningful value in terms of evaluating context or correctness. IMO, the only result is mass MEGO.
The question is, "Is Code Review Good?" I believe it is in theory, if it worked, but in practice it doesn't. So I believe the answer is, do it all the time, not as an exercise in seeing how many people you can get to come up with different opinions on where to put a curly brace!
How do you do it to make it work? How do you do it to make it work all the time? The only answer I have found that actually works is Pair Programming.
Don't trust your programmers to know what they're doing? To work cooperatively with each other instead of building cowboy kingdoms of knowledge? To share their knowledge and take the time to do the most difficult of all programming tasks: communicate?
The answer my friends is simple: If you don't trust them, FIRE THEM!
Slashdot Mirror
Actually.... QKS a Smalltalk vendor for the last 10 years, is working with Microsoft to produce SmallScript.
.NET. It is being developed "With" Microsoft in the same way that the Eiffel people are developing a version of Eiffel for .NET with Microsoft... IOW, it won't be a MS product, MS is just lending a hand to get Yet Another Language on their .NET platform.
.NET... or the lack of same.
It is a new scripting based Smalltalk that runs (will run) on
This of course has nothing to do with the evilness of MS or the foolishness of
And So It Goes
"Refactor Mercilessly" -- "Wasted Time"
You might not like this answer then. You didn't Refactor Mercilessly. Refactoring as a discreet development task is almost always a waste of time. Refactoring as a part of the process of adding or modifying a feature, as an intrinsic way of developing never is. The Refactoring you talk about is simply the rearranging the deck chairs on the Titanic. The Refactoring I talk about is the constant incremental improvement of code to assure that it always matches the current Best Vision of what the product/function should be.
"Simplest Thing That Can Possibly Work" -- "Almost nothing of what we do is simple"
Well, I work on enterprise applications, and I assure you, they are not simple either. Don't confuse E-Z with Simple. Simple is almost never E-Z. And it isn't about "as simple as possible" either! The simplest thing that can possibly work is often very hard, complex work. But it NEVER is more than is needed. It never attempts to guess what I will need tomorrow, only what I need today. Then, coupled with Refactoring as a intrinsic part of development, I am unafraid to add what is needed tomorrow, when I know what it is. Each identifiable increment is then the most simplest thing that can possibly work. The difficulty or ease in doing it has nothing to do with this idea.
"Embrace Change" -- "does not mean ignoring planning and re-use."
Mostly, I agree with your statements. I though have yet to see anyone accurately predict what the future will bring, and therefore, it is better to take a position of Embracing Change instead of pretending you can predict the future. Planning for now is one thing. Pretending one can accurately plan for the future is one of the "Big Lies" of our industry. One of the other "Big Lies" of our industry is being able to plan for Re-use. Constant incremental refactoring is Re-use in practice, there really is nothing else except the puffed up statements of supposed computer industry experts (an oxymoron at that!).
"Frozen at the end of Design" -- "You're Ignorant"
Well, whether I'm ignorant or not is not in dispute here. What is in dispute is if "Traditional" software design techniques imply feature sets are frozen at the end of design. I suggest you go back and read the traditional Waterfall process texts, and find where they imply where the features change within an iteration. I don't consider Spiral methods to be Traditional, but that could be a matter of opinion where we might disagree. Even so, in practice, none of these takes into account how to deliver on time, and still react immediately to new feature requests. XP's Planning Game, Stories, Engineering Tasks and Full Time Business Person does address this.
"Accurately Estimate Time" -- "(Three Distinct Questions)"
Question 1: XP Time increments are exact. At the end of every increment, there is a tangible deliverable, and there is no question that it is exactly what the Business User agrees with.
Question 2: Of course, all managers want to have time estimates. How its done changes, not the need.
Question 3: Yes. Except of course, it's not magic, its hard work.
And So It Goes
You have made a fundamental mistake. You have equated "No Individual Code Ownership" with "No Code Ownership."
While this is a common mistake, it is not what XP professes. XP says there must be Communal Code Ownership. Instead of "Individual Code Ownership" where it's "My Code vs Their Code (And I'll do everything in my power to protect MY code from 'Them', those morons)", there is just "Our Code!"
The pride you speak of is cowboy pride. Pride in keeping my code working while all of the other morons screw up. It's the pride that leads to "Well, MY code worked!" How sad. Worse... it is frightfully pervasive.
There is another pride possible. "Our Code Works", and "I Contributed To Making Our Code Work", and "I Was Successful In Helping Our Project Be Wildly Successful!"
I have personally always found the former to be shallow and ultimately, unproductive, while latter to be the only truly satisfying form of pride I have ever experienced.
And So It Goes
Yeah, I'd like to see one too.
Haven't yet in 20 years in this business. I have time and again asked my Colleagues over the years if any one of them have seen one, but they haven't.
So I no longer believe they exist, any more than the Tooth Fairy, Hanukkah Harry, Compassionate Lawyers or Honorable Politicians.
That's why I support XP. It finally puts to rest the notion that what hasn't yet worked, should work, and will work, if we only somehow believe it harder... Maybe by clapping our hands together and chanting "I Believe In Detailed Specifications... I Believe In Detailed Specifications..." until Tinker Bell comes back to life.
Detailed Specifications are like UFOs. Some people want to believe they exist, and that someone out there has actually seen them. However while the evidence doesn't stand up to the light of day, it doesn't seem to diminish the large amount that is written about them, nor the hope that someday we'll prove they actually exist, despite the government cover-up.
It's too bad you don't consider work 'coding for fun.' It speaks volumes about the failure of the processes and procedures that pervade the industry. For me, its always fun. So much so, that I don't feel the want to hack at home much anymore. As a matter of fact, I tend to dislike it because I don't have anyone to work with. But then, I'm a consultant, and when I find a place that isn't fun, I just move on.
And So It Goes
You're right of course.. IF.
If you do not Refactor Mercilessly.
If you do not have Unit Tests covering all code.
If you do not pursue the Simplest Thing That Can Possibly Work.
If you do not work in pairs.
If you do not Embrace Change.
--AND--
If you think that todays Design Document will cover all of tomorrows problems.
If you think the Design & Analysis Documents will exactly match the finished product.
If you think the feature set is frozen at the end of Design.
If you think you can accurately estimate the time for implementation before it starts.
--OR--
You can do it with XP, and realize it MUST work without one of those boring library design meetings. Because it hasn't worked yet, your way.
And So It Goes
Isn't it interesting.
Isn't it interesting that all through our school years, we are told over and over that working WITH another is cheating. And what happens the first time we get out in the business world? We're told "We want team players!"
But we have no experience in doing that. So, as programmers, we talk the talk of "Team" and Tony What's-His-Name and sharing and empowerment, but the moment we start to work, we revert to the Cowboy ethic, which is, after all, the only thing we know.
The very idea of Pair Programming and Communal Code Ownership is so foreign to us as to not even make sense to us. It doesn't seem rational much less possible.
So we just say "It Doesn't Work", "It's Less Productive", "If Only We Did Right What We're Doing Now, We Wouldn't Be Talking About This Idiotic Fantasy"
And there in a nutshell is the problem. XP is an attempt to define a process where "YOU" are truly empowered, not just some lip service where in the end you just go back to your closed door office and pound the keyboard, Twinkie and Latte in hand.
"But Sharing Gets Me Nowhere!" you say in the quiet of your mind. "Power and career advancement does not come from sharing." True enough. In the "Real World" it comes from having knowledge and demonstrating ability that others do not have. This XP stuff all seems like some Utopian world where everyone knows the project that they're working on, can help anyone on their team with any part of the project, can be unafraid to attack a new or old part of the project that they've never seen before, to try new things all the time without worry that it will break something.
Yup. It's purely the things dreams are made of. Except... Except... It works. When all is said and done, and you do all of the practices, and you put your pride on the line that you will do the best for the PROJECT and the PROCESS as a whole instead of your small corner of the world, it works.
But that would be cheating!
And So It Goes
Sorry about the double post,
And So It Goes
Because no one does it!
Let's get real. Most Code-Review is a waste of time. Hours and hours of person time is wasted in what seems like should work, but never has.
What usually happens is a bunch of people sit around in endless dreadful meetings, looking at lifeless code listings, making superfluous comments about style and imagined execution. They are as a whole, unable provide ANY meaningful value in terms of evaluating context or correctness. IMO, the only result is mass MEGO.
The question is, "Is Code Review Good?"
I believe it is in theory, if it worked, but in practice it doesn't.
So I believe the answer is, do it all the time, not as an exercise in seeing how many people you can get to come up with different opinions on where to put a curly brace!
How do you do it to make it work? How do you do it to make it work all the time? The only answer I have found that actually works is Pair Programming.
Don't trust your programmers to know what they're doing? To work cooperatively with each other instead of building cowboy kingdoms of knowledge? To share their knowledge and take the time to do the most difficult of all programming tasks: communicate?
The answer my friends is simple: If you don't trust them, FIRE THEM!
And So It Goes