Comment Re:Library Coding Tip (Score 1) 222
"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 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
