It is wothless shit as far as any more serious task is concerned.
Bold talk. Where's your evidence?
Although I haven't used the Prevayler code in a production system, I've done similar always-hot systems without databases. It works fine for many uses.
The Prevayler scalability test (which you can download and run yourself) is hundreds to thousands of times faster than using an SQL database. Meaning that unless you've already using hundreds of servers to handle your load, then you can run an equivalent prevaylent system on one box.
Sure, you have to have enough RAM for your data. But an awful lot of commercial systems will fit happily into a couple GB of RAM. And RAM is very cheap these days.
All the Colo's I've hosted at have had monitors (along with keyboard/mouse) on wheels, which you pull it over to your rack and plug it in.
I used to host some gear at Level3. When we moved there in 1998, they had nice carts. Since they were good folks as well, we lent them one of those old Sun monitors; we needed it for some of our boxes, and thought it would be nice to share.
A year or so later, they decided the carts were too much trouble to maintain, complaining that people tended to forget and put the mouse in their cabinet. So did they take three seconds and a 3-cent cable tie to attach the mouse permanently? No, they got rid of every one. Including the one with our monitor. Bastards.
A cynical person would note that getting rid of the carts means you have to buy rack space for your monitors. Ergo, more money for them. I'm not that cynical, of course. But that doesn't mean that Level3's execs aren't.
Regardless, that was one of the things that pushed us to move to new colo.
But now, with the onset of Broadband Internet, the pieces that can be sent through the net are much bigger.
That's correct. You may hear people talk about bandwidth in terms of OC units, as in, "We just got another OC3 pulled into our cabinet."
That stands for "office cubicle", and it's a standardized unit of bandwidth measurement. The reference OC is a volume 6' x 8' x 8', with a certain distribution of solid matter (excluding the worker, of course). An OC3 allows you to transfer 3 standard cubicles per hour. Actual transfer speeds depend on density, of course. The building core will take more time, and things like corridors and auditoriums take a lot less.
what about the performance of.jsp and the like on non-massive hardware?
It depends on how well you code.
JSPs are translated to Java exactly once, so the performance is equivalent to regular Java servlets. For a good coder and using a modern VM with the run-time optimization, you can get performance reasonably close to what you can get with C.
For one of my clients I built a pretty complex dynamic site. On the generic P733 box I have handy, I can easily pull 20 megabits, even though I've spent almost no time optimizing the site.
The reason you see a lot of slow JSP sites is that Java is the language of choice for large corporate shops. On average, these outfits have many drawbacks:
Many of them pull data from large, slow databases or mainframe systems.
Many of them employ mediocre programmers who value job safefty above all else.
A fondness for process means that making big changes is hard.
A fondness for high-headcount teams makes it hard to get a coherent design and even harder to change anything later.
Throwing money at a problem is generally favored over thinking, especially if said thinking would result in opinions that would make somebody look bad.
And that's just getting started. One of my clients had a team of twenty spend two years developing a site that was deployed on $2m in fancy hardware and software licenses. With three top-notch developers, I could have redone the whole thing in four months and run it all on maybe $10k of generic Intel hardware and free software.
Of course, they never would have let me; even if one development manager had taken the risk, the others would have done everything they could to sabotage the project, as it would have made them look bad.
Sony and friends don't offer non-Windows laptops because IT WOULD COST THEM MONEY!
Oh, please. Have you ever played will Dell's on-line configurator? If they can give you that many options, installing Windows or not is a piece of cake.
Your rant makes more sense in a retail context. But even there, it would be pretty easy for any determined company to offer multiple OSes on the same hardware.
How? At the factory, they put images for all the OSes on the hard drive. When you turn it on for the first time, it asks you what OS you want to run. If you pick the standard consumer choice, it says "ok" and carries on. If you pick one of the high-priced OSes, you give your credit card number via modem or human operator. And if you pick Linux, they give you a magic number that you fill in on a web site to get a refund. And then whatever you pick, the installer blows away the other OS images and gives you the space.
So although there are many reasons a vendor might not offer Linux, the difficulty of keeping their build and stock processes straight shouldn't be one of them.
"Extreme" Programming must be one of the most idiotic buzz words to ever come out of the software industry.
I agree that it's a stupid name. On the other hand, XP gets more ink and chatter than all the other Agile methods combined. So stupid or not, the name worked.
Basically, "Extreme" (God - it makes me cringe just to type it!) programming means "doing it right"
This got modded as "informative"? Please.
XP has a number of practices that aren't common, certainly not in combination. The name may be stupid, but the practices kick ass. They've made my software better; they've made me and my clients happier. If you want to let the name keep you away from that, go right ahead.
For this to work, you already need to have a relationship with the client. Once they trust that you aren't going to screw them, they're much more willing.
Also, optional scope contracts have big benefits for the purchaser. For a long project, the ability to kill it with two weeks notice drastically reduces risk on their part.
And if I'm doing optional scope, I can charge them less because I have to set aside less cushion for risk. One company I know offered an optional scope contract at $X and a fixed-scope contract at $1.5X.
So it's certainly not impossible, although I agree it's hard.
Other XP proponents might say to hide the process from the client and make an XP project look, to the outside, like a waterfall with very flexible change management, but I wasn't happy with that sort of methodological dishonesty.
What's dishonest? If I sign a contract for a fixed spec and fixed price with change fees, then I don't have a problem telling the client that internally I'm using XP if they ask.
If I've already recommended an optional-scope contract and they turn it down, the fact that I will make a killing on the change fees is their problem, not mine.
Now that the hype has died down, my question is this: How many people out there are really doing XP? How much has this really caught on? Is it just a bunch of talk?
The summer 2002 XPUniverse conference was circa twice the size of 2001. I expect that this year's growth will be at least 50%.
But there was certainly a difference in tone between the two years. There was still a lot of evangelistic fervor, but there were a lot more average joes who were using it because it worked for them.
Regarding your questions, I've been using it for dynamic web sites and application provided via the web. It works for me stunningly well. I make better software. I get more sleep. Both I and my clients are happier and more relaxed.
For more info, drop by the XP mailing list; there are a lot of friendly people there.
Except form that fact that you only need half the PC's, there are no real cost cutting, not in larger projects at least.
I'm not sure that's the case. XP's scope control techniques have cut costs substantially in the projects I've done. Ditto for the defect reduction. Is your experience different?
Eventhough lots of people talk about MVC and Model 2 stuff, very few people actually implement solutions that way: it takes more planning, the code/build/test cycle is longer, etc. People cut corners, it's a fact of life.
And most software projects also fail. There's a correlation.
Cutting corners with software is generally a false economy. You may get to the first release faster, but cut corners add up exponentially. By starting out cutting corners, you're betting that the project will fail.
Instead of cutting quality, wouldn't it be better to cut out useless work?
I don't think I've ever seen a requirements document that isn't at least half fluff. In XP, every week you force the product manager to pick the very most important features to work on. On an XP project, most of fluff never rises to the top of the pile. Once you cut that crap out, there's plenty of time to do quality work.
And if you're doing test-driven design and pair programming, your bug counts will likely drop by an order of magnitude. If you spend hardly any time on debugging, that frees up a lot of time, too.
In our current project, we've achieved a reliability improvement of almost 2 orders of magnitude based on our XP methodology, and it's increasing every day.
This matches my experience, too. I'm well below one shipped bug per man-month.
The XP folks seem to suggest maitaining unit tests at a level I consider excessive. I think they suggest one test per non-trivial method on all classes.
There are two common phrases to sum up what to test in XP:
Test anything that could reasonably break.
and
Only test the things you want to work.
What that actually maps to in your code depends a lot on your code. But I think the most important rule is that if a bug gets through despite my tests, it's a sign that I guessed wrong about what to test.This just seems too much, and very hard to achieve, since even in the best designed projects, individual methods are hard to test without also testing a bunch of other stuff.
It's true that it's hard, but there are a variety of techniques to make it easier. The more I do test-driven design, the more I discover that when an object is hard to test, it's a sign that I should improve the design generally by reducing coupling and simplifying my objects.
It sounds like your project was suffering mainly from a lack of design skills.
Yeah, XP gets beat with this stick a lot: "We took a bunch of novices and they produced a system that was poorly designed! It must be the fault of XP!"
I think that no matter what level of design skill a team has, XP is a great way to make the best use of that skill. But people shouldn't fool themselves: making complex software requires substantial design expertise, and a team without a good percentage of grizzled veterans is on the the short road to critical mass.
GINORMOUS! 9MB for "Hello, World"? 900MB for a UML application?!??!?!
I certainly agree that the Sun JVM is a pig. But TogetherJ isn't just a UML app it's an over-the-top, all-singing, all-dancing IDE, with a ridiculous feature set. So Java doesn't take all the blame for that.
That's a bold assertion, but not true, otherwise iterative software development (e.g., Extreme Programming, SCRUM, FDD, etc.) would be impossible.
Think of it as like a New York to San Francisco road trip for somebody who doesn't know the route. It's possible to just hop in your car and head for the setting sun. It's also possible to plan every single movement of the wheel in advance, with detailed contingencies for every possible disturbance to you plan.
The first way is pretty risky. The second way will waste a lot of time and effort. Best value comes from doing just enough planning now to get you to the point where you need to do more planning.
I'm not advocating willful blindness, by any means, but it's certainly possible to spend too much time worrying about the many possibilities the future can bring.
Architecture should be part of the process. XP describes a process without explicit steps for architecture.
Architecture is part of the process. Beck and others mention it; the teams I'm familiar with have no problem with it. There is no explicit step because they see it as all part of "design" and "refactoring", which are explicit steps already.
XP attempts to be scale-free. If you want to impose scale distinctions, fine, but recognize that it's not part of XP.
Each iteration included 'tests' (in the form of human walk throughs) to ensure adherence to design and refactoring of the design itself. Just like the code, we iterated over the design.
Why wasn't this happening naturally?
For adherence to the architecture, that's everybody's job. And if they forget, they have a pair to keep them in line. Sure, some people are more architecture-savvy than others, but since pairs should change a lot, those people should be able to influence the design as needed. Why wasn't that happening in your team?
As far as refactoring of the architecture it's not clear to me how a part of the architecture could be bad enough to need refactoring without anybody noticing that it was a pain. When they feel they pain, they should raise their voice a little and say, "Has anybody thought about X?"
Even if they don't raise it right then, they should be raising things at the next daily stand-up, yes? Were they doing that in your team?
Also, generally at release and iteration planning meetings we'll talk over architectural issues when new stories or tasks inspire their discussion. Didn't this happen for y'all?
We added the rituals.
Did you do this in response to an actual problem? E.g., that you got two months into and discovered that y'all were letting the architecture get crufty? Or was it imposed from the beginning based on theoretical concerns?
If the former, I'd agree that one way to solve that is adding an additional ritual every iteration. And bravo for fixing the problem you had! But there are other ways to solve the problem, too.
Saying, "My team had a problem adopting XP and we did this to fix it," is a pretty different thing than saying, "XP has a fundamental flaw."
If you want to claim that *you* are using higher level constructs, then fine. But you are doing something *in addition* to what XP suggests, which is exactly what I was saying should be done.
No, I'm doing exactly what XP says to do. Since design is good, I do that in the most extreme fashion possible: I design all the time. Sometimes that's small stuff; sometimes that's big stuff. Whenever big issues come up, I do big design.
Pulling out Kent Beck's book "Extreme Programming Explained", I note that there are four different entries for architecture, which is the common name for the high-level design that you're talking about:
Architecture
design strategy and, 113
exploration phase and, 132
guiding metaphor and, 56-7
iterations and, 134
Looking through these pages, I find a number of relevant quotes:
System Architecture I haven't used the "A" word anywhere abouve. Architecture is jsut as important in XP projects as it is in any software project. [...]
For the first iteration, pick a set of simple, basic stories that you expect will force you to ctreate the whole architecture. Then narrow your horizon and implement the stories in the simplest way that can possibly work. At the end of this exercise you will have your architecture. It may not be the architecture you expected, but then you will have learned something.
[...]
The programmers should also experiment with architectureal ideas -- how do you build a system for multiple levels of undo? Implement it three different ways for a day and see which feels best. These little architectural explorations are most important when you find the user coming up with stories that you have no idea how to implement.
So as far as I can tell, XP's attitude is that yes, architecture is important, and that yes, you should pay attention to it, but that there are no special rituals regarding it.
What special rituals do you want? And when you did XP, what architectural problems did your team have without those special rituals?
Again, we're parsing definitions. When most people speak of software design they are not speaking of the design of a 30 line routine, but rather of a module, subsystem or large unit. That was how I used the term, read my note in that context.
Yes, and I'm saying that they are the same thing. The techniques may be different, but the principles are the same. Someone who can't write good code will never make a great "architect", and somebody who has no clue about the bigger picture is a dangerous coder.
The high level view is important and, I think, mostly ignored in XP.
The fact that nobody explicitly says, "Hey, don't forget the big picture," doesn't mean that XP pracitioners don't pay attention to the big picture.
On the XP projects I've been on, we talk about the big picture with frequency. Little issues with object lifecycles lead us to examine and perhaps change our persistence layer. The recognition that some packages are annoying for us to work on because they have too many classes sometimes leads to a major code reorganization.
Note that some of the people involved in XP are people who are very interested in design on the larger scale. Martin Fowler, for example, has written entire books about UML and Enterprise Architecture. Many XP practitioners are also very involved in the Patterns movement.
You are right about one thing though, I shouldn't say "they don't scale". What I should say is that they don't scale as well as a more comprehensive approach.
Unless you want to come up with some statistics, I'm going to translate this as, "I think they don't scale [...]" or maybe, "I don't know how to make them scale".
People are using XP (and other Agile methods) on projects with large code bases. They seem to think it works well. Perhaps you should drop by a mailing list and find out how they're doing it. Arguing is always more fun once you have some facts.
Then, arguably, this isn't refactoring but something simpler.
Refactoring is improving the design of existing code. Be it 10^1 or 10^6 lines, if you're changing the design without changing the functionality, it's refactoring.
In any case, to leave terminology aside, my point is that design is a higher level thing that helps 100K lines look, feel and behave similarly. XP doesn't address this well.
Design is design. A program can have good or bad design at many levels of abstraction. You're right that it's important to look at the high-level ones, but many of the important clues about high-level design lie in how things are working on smaller scales.
As far as I can tell, any refactoring of big issues can be broken down into a series of tiny refactorings. One's notions about the big picture are played out in one's small actions. As an analogy, think of a cross-continental road trip. The fact that I'm going from San Francisco to New York has at least a little influence on every move of the wheel, and a lot of influence on some of them.
See above, I wasn't referring to the small work units. I agree 100% that the XP ideas work really well on the time scale of a day or a week, but they don't scale to a project or a large team.
A bold assertion. Do you mean to say that you've been unable to do it? That it's utterly impossible for anybody to do it based on some mathematical proof you have? Or just that you can't currently see how it would work?
If Knuth had believed that the way you're making it look, he'd never have written The Art of Programming.
Oh, please. Knuth is also a strong advocate of Literate Programming, the notion that code should be treated first as a piece of literature.
There's nothing inconsistent here. Nobody, not me, not Knuth, not Fowler, is avocating stupid programming. Yes, you should be a master of algorithms, and yes, you should design so that later optimization is possible. But that shouldn't get in the way of writing clear, readable code except when you have the numbers to prove that performance is a real-world issue.
And I will assert boldly that most of the optimization people do without profiling first is just a waste of money. I've never had to throw out inherited code just because it was too slow. Instead, the stuff I chuck is because it's too big a pain to work on.
It sounds to me like this is just another way of designing, but that makes the wrong emphasis. These tests sound a lot like low level use-cases. You should be creating those anyways. But you should create all of those first! Not one at a time as you code.
Should? What, because it was written on the back of the stone tablets that Moses brought down?
Hi, I've tried it both ways. Test-driven design and refactoring work. It's possible to build good software both ways. In my opinion, TDD and refactoring are more productive and more fun. But hey, you're welcome to stick with your stone tablets if you want.
Requirements are the Achilles heel of XP. Without rock solid requirements, you are just guessing for the test scripts.
Spoken like a guy who has never done XP.
One of the core requirements of XP is known as the On-site Customer. This means that there should be somebody at all the meetings and sitting within shouting distance of the programmers, somebody who can answer questions like that or find out the answers. (In some companies this person is called a Product Manager; in others a Business Analyst).
I could only dream for mediocre requirements
Yes, requirements documents are generally silly. That's why XP doesn't use them. Instead of waving around some phone-book sized pile of garbage, XP practitioners use high-bandwidth, low-latency communications techniques: they talk. And they try out new versions of the software every week.
At least enough to try and read their minds.
Yep! And get yelled at when it turns out you don't have psychic powers. 'Cause that's what it takes to make standard development practices work. Isn't that a sign we should try something different?
Slashdot Mirror
It is wothless shit as far as any more serious task is concerned.
Bold talk. Where's your evidence?
Although I haven't used the Prevayler code in a production system, I've done similar always-hot systems without databases. It works fine for many uses.
The Prevayler scalability test (which you can download and run yourself) is hundreds to thousands of times faster than using an SQL database. Meaning that unless you've already using hundreds of servers to handle your load, then you can run an equivalent prevaylent system on one box.
Sure, you have to have enough RAM for your data. But an awful lot of commercial systems will fit happily into a couple GB of RAM. And RAM is very cheap these days.
All the Colo's I've hosted at have had monitors (along with keyboard/mouse) on wheels, which you pull it over to your rack and plug it in.
I used to host some gear at Level3. When we moved there in 1998, they had nice carts. Since they were good folks as well, we lent them one of those old Sun monitors; we needed it for some of our boxes, and thought it would be nice to share.
A year or so later, they decided the carts were too much trouble to maintain, complaining that people tended to forget and put the mouse in their cabinet. So did they take three seconds and a 3-cent cable tie to attach the mouse permanently? No, they got rid of every one. Including the one with our monitor. Bastards.
A cynical person would note that getting rid of the carts means you have to buy rack space for your monitors. Ergo, more money for them. I'm not that cynical, of course. But that doesn't mean that Level3's execs aren't.
Regardless, that was one of the things that pushed us to move to new colo.
But now, with the onset of Broadband Internet, the pieces that can be sent through the net are much bigger.
That's correct. You may hear people talk about bandwidth in terms of OC units, as in, "We just got another OC3 pulled into our cabinet."
That stands for "office cubicle", and it's a standardized unit of bandwidth measurement. The reference OC is a volume 6' x 8' x 8', with a certain distribution of solid matter (excluding the worker, of course). An OC3 allows you to transfer 3 standard cubicles per hour. Actual transfer speeds depend on density, of course. The building core will take more time, and things like corridors and auditoriums take a lot less.
Heh. When they said that a LOC was Slashdot's favorite unit of storage, I was thinking it meant "load of crap".
It depends on how well you code.
JSPs are translated to Java exactly once, so the performance is equivalent to regular Java servlets. For a good coder and using a modern VM with the run-time optimization, you can get performance reasonably close to what you can get with C.
For one of my clients I built a pretty complex dynamic site. On the generic P733 box I have handy, I can easily pull 20 megabits, even though I've spent almost no time optimizing the site.
The reason you see a lot of slow JSP sites is that Java is the language of choice for large corporate shops. On average, these outfits have many drawbacks:
And that's just getting started. One of my clients had a team of twenty spend two years developing a site that was deployed on $2m in fancy hardware and software licenses. With three top-notch developers, I could have redone the whole thing in four months and run it all on maybe $10k of generic Intel hardware and free software.
Of course, they never would have let me; even if one development manager had taken the risk, the others would have done everything they could to sabotage the project, as it would have made them look bad.
Sony and friends don't offer non-Windows laptops because IT WOULD COST THEM MONEY!
Oh, please. Have you ever played will Dell's on-line configurator? If they can give you that many options, installing Windows or not is a piece of cake.
Your rant makes more sense in a retail context. But even there, it would be pretty easy for any determined company to offer multiple OSes on the same hardware.
How? At the factory, they put images for all the OSes on the hard drive. When you turn it on for the first time, it asks you what OS you want to run. If you pick the standard consumer choice, it says "ok" and carries on. If you pick one of the high-priced OSes, you give your credit card number via modem or human operator. And if you pick Linux, they give you a magic number that you fill in on a web site to get a refund. And then whatever you pick, the installer blows away the other OS images and gives you the space.
So although there are many reasons a vendor might not offer Linux, the difficulty of keeping their build and stock processes straight shouldn't be one of them.
Developers will be disappointed but educated; sysadmins will be pleased and educated.
Speaking as a recovering sysadmin, isn't "pleased" a little strong to describe the mental state of a sysadmin?
"Extreme" Programming must be one of the most idiotic buzz words to ever come out of the software industry.
I agree that it's a stupid name. On the other hand, XP gets more ink and chatter than all the other Agile methods combined. So stupid or not, the name worked.
Basically, "Extreme" (God - it makes me cringe just to type it!) programming means "doing it right"
This got modded as "informative"? Please.
XP has a number of practices that aren't common, certainly not in combination. The name may be stupid, but the practices kick ass. They've made my software better; they've made me and my clients happier. If you want to let the name keep you away from that, go right ahead.
Optional scope contracts just wouldn't fly.
For this to work, you already need to have a relationship with the client. Once they trust that you aren't going to screw them, they're much more willing.
Also, optional scope contracts have big benefits for the purchaser. For a long project, the ability to kill it with two weeks notice drastically reduces risk on their part.
And if I'm doing optional scope, I can charge them less because I have to set aside less cushion for risk. One company I know offered an optional scope contract at $X and a fixed-scope contract at $1.5X.
So it's certainly not impossible, although I agree it's hard.
Other XP proponents might say to hide the process from the client and make an XP project look, to the outside, like a waterfall with very flexible change management, but I wasn't happy with that sort of methodological dishonesty.
What's dishonest? If I sign a contract for a fixed spec and fixed price with change fees, then I don't have a problem telling the client that internally I'm using XP if they ask.
If I've already recommended an optional-scope contract and they turn it down, the fact that I will make a killing on the change fees is their problem, not mine.
The point is that both parties enter into the contract willingly and freely. So what can be unfair about that ?
That's certainly fair, but that's not the point.
If I can find a way to better share the risks and rewards with my clients or contractors, then generally strikes both me and them as more fair.
Now that the hype has died down, my question is this: How many people out there are really doing XP? How much has this really caught on? Is it just a bunch of talk?
The summer 2002 XPUniverse conference was circa twice the size of 2001. I expect that this year's growth will be at least 50%.
But there was certainly a difference in tone between the two years. There was still a lot of evangelistic fervor, but there were a lot more average joes who were using it because it worked for them.
Regarding your questions, I've been using it for dynamic web sites and application provided via the web. It works for me stunningly well. I make better software. I get more sleep. Both I and my clients are happier and more relaxed.
For more info, drop by the XP mailing list; there are a lot of friendly people there.
Except form that fact that you only need half the PC's, there are no real cost cutting, not in larger projects at least.
I'm not sure that's the case. XP's scope control techniques have cut costs substantially in the projects I've done. Ditto for the defect reduction. Is your experience different?
Eventhough lots of people talk about MVC and Model 2 stuff, very few people actually implement solutions that way: it takes more planning, the code/build/test cycle is longer, etc. People cut corners, it's a fact of life.
And most software projects also fail. There's a correlation.
Cutting corners with software is generally a false economy. You may get to the first release faster, but cut corners add up exponentially. By starting out cutting corners, you're betting that the project will fail.
Instead of cutting quality, wouldn't it be better to cut out useless work?
I don't think I've ever seen a requirements document that isn't at least half fluff. In XP, every week you force the product manager to pick the very most important features to work on. On an XP project, most of fluff never rises to the top of the pile. Once you cut that crap out, there's plenty of time to do quality work.
And if you're doing test-driven design and pair programming, your bug counts will likely drop by an order of magnitude. If you spend hardly any time on debugging, that frees up a lot of time, too.
In our current project, we've achieved a reliability improvement of almost 2 orders of magnitude based on our XP methodology, and it's increasing every day.
This matches my experience, too. I'm well below one shipped bug per man-month.
There are two common phrases to sum up what to test in XP:andWhat that actually maps to in your code depends a lot on your code. But I think the most important rule is that if a bug gets through despite my tests, it's a sign that I guessed wrong about what to test.This just seems too much, and very hard to achieve, since even in the best designed projects, individual methods are hard to test without also testing a bunch of other stuff.
It's true that it's hard, but there are a variety of techniques to make it easier. The more I do test-driven design, the more I discover that when an object is hard to test, it's a sign that I should improve the design generally by reducing coupling and simplifying my objects.
It sounds like your project was suffering mainly from a lack of design skills.
Yeah, XP gets beat with this stick a lot: "We took a bunch of novices and they produced a system that was poorly designed! It must be the fault of XP!"
I think that no matter what level of design skill a team has, XP is a great way to make the best use of that skill. But people shouldn't fool themselves: making complex software requires substantial design expertise, and a team without a good percentage of grizzled veterans is on the the short road to critical mass.
GINORMOUS! 9MB for "Hello, World"? 900MB for a UML application?!??!?!
I certainly agree that the Sun JVM is a pig. But TogetherJ isn't just a UML app it's an over-the-top, all-singing, all-dancing IDE, with a ridiculous feature set. So Java doesn't take all the blame for that.
There is no such thing as "premature design".
That's a bold assertion, but not true, otherwise iterative software development (e.g., Extreme Programming, SCRUM, FDD, etc.) would be impossible.
Think of it as like a New York to San Francisco road trip for somebody who doesn't know the route. It's possible to just hop in your car and head for the setting sun. It's also possible to plan every single movement of the wheel in advance, with detailed contingencies for every possible disturbance to you plan.
The first way is pretty risky. The second way will waste a lot of time and effort. Best value comes from doing just enough planning now to get you to the point where you need to do more planning.
I'm not advocating willful blindness, by any means, but it's certainly possible to spend too much time worrying about the many possibilities the future can bring.
(think: Mickey and Goofy)
You mean as in "large oppressive media companies" and "crazy, ridiculous, or ludicrous"?
Architecture should be part of the process. XP describes a process without explicit steps for architecture.
Architecture is part of the process. Beck and others mention it; the teams I'm familiar with have no problem with it. There is no explicit step because they see it as all part of "design" and "refactoring", which are explicit steps already.
XP attempts to be scale-free. If you want to impose scale distinctions, fine, but recognize that it's not part of XP.
Each iteration included 'tests' (in the form of human walk throughs) to ensure adherence to design and refactoring of the design itself. Just like the code, we iterated over the design.
Why wasn't this happening naturally?
For adherence to the architecture, that's everybody's job. And if they forget, they have a pair to keep them in line. Sure, some people are more architecture-savvy than others, but since pairs should change a lot, those people should be able to influence the design as needed. Why wasn't that happening in your team?
As far as refactoring of the architecture it's not clear to me how a part of the architecture could be bad enough to need refactoring without anybody noticing that it was a pain. When they feel they pain, they should raise their voice a little and say, "Has anybody thought about X?"
Even if they don't raise it right then, they should be raising things at the next daily stand-up, yes? Were they doing that in your team?
Also, generally at release and iteration planning meetings we'll talk over architectural issues when new stories or tasks inspire their discussion. Didn't this happen for y'all?
We added the rituals.
Did you do this in response to an actual problem? E.g., that you got two months into and discovered that y'all were letting the architecture get crufty? Or was it imposed from the beginning based on theoretical concerns?
If the former, I'd agree that one way to solve that is adding an additional ritual every iteration. And bravo for fixing the problem you had! But there are other ways to solve the problem, too.
Saying, "My team had a problem adopting XP and we did this to fix it," is a pretty different thing than saying, "XP has a fundamental flaw."
No, I'm doing exactly what XP says to do. Since design is good, I do that in the most extreme fashion possible: I design all the time. Sometimes that's small stuff; sometimes that's big stuff. Whenever big issues come up, I do big design.
Pulling out Kent Beck's book "Extreme Programming Explained", I note that there are four different entries for architecture, which is the common name for the high-level design that you're talking about:Looking through these pages, I find a number of relevant quotes:
So as far as I can tell, XP's attitude is that yes, architecture is important, and that yes, you should pay attention to it, but that there are no special rituals regarding it.
What special rituals do you want? And when you did XP, what architectural problems did your team have without those special rituals?
Again, we're parsing definitions. When most people speak of software design they are not speaking of the design of a 30 line routine, but rather of a module, subsystem or large unit. That was how I used the term, read my note in that context.
Yes, and I'm saying that they are the same thing. The techniques may be different, but the principles are the same. Someone who can't write good code will never make a great "architect", and somebody who has no clue about the bigger picture is a dangerous coder.
The high level view is important and, I think, mostly ignored in XP.
The fact that nobody explicitly says, "Hey, don't forget the big picture," doesn't mean that XP pracitioners don't pay attention to the big picture.
On the XP projects I've been on, we talk about the big picture with frequency. Little issues with object lifecycles lead us to examine and perhaps change our persistence layer. The recognition that some packages are annoying for us to work on because they have too many classes sometimes leads to a major code reorganization.
Note that some of the people involved in XP are people who are very interested in design on the larger scale. Martin Fowler, for example, has written entire books about UML and Enterprise Architecture. Many XP practitioners are also very involved in the Patterns movement.
You are right about one thing though, I shouldn't say "they don't scale". What I should say is that they don't scale as well as a more comprehensive approach.
Unless you want to come up with some statistics, I'm going to translate this as, "I think they don't scale [...]" or maybe, "I don't know how to make them scale".
People are using XP (and other Agile methods) on projects with large code bases. They seem to think it works well. Perhaps you should drop by a mailing list and find out how they're doing it. Arguing is always more fun once you have some facts.
Then, arguably, this isn't refactoring but something simpler.
Refactoring is improving the design of existing code. Be it 10^1 or 10^6 lines, if you're changing the design without changing the functionality, it's refactoring.
In any case, to leave terminology aside, my point is that design is a higher level thing that helps 100K lines look, feel and behave similarly. XP doesn't address this well.
Design is design. A program can have good or bad design at many levels of abstraction. You're right that it's important to look at the high-level ones, but many of the important clues about high-level design lie in how things are working on smaller scales.
As far as I can tell, any refactoring of big issues can be broken down into a series of tiny refactorings. One's notions about the big picture are played out in one's small actions. As an analogy, think of a cross-continental road trip. The fact that I'm going from San Francisco to New York has at least a little influence on every move of the wheel, and a lot of influence on some of them.
See above, I wasn't referring to the small work units. I agree 100% that the XP ideas work really well on the time scale of a day or a week, but they don't scale to a project or a large team.
A bold assertion. Do you mean to say that you've been unable to do it? That it's utterly impossible for anybody to do it based on some mathematical proof you have? Or just that you can't currently see how it would work?
If Knuth had believed that the way you're making it look, he'd never have written The Art of Programming.
Oh, please. Knuth is also a strong advocate of Literate Programming, the notion that code should be treated first as a piece of literature.
There's nothing inconsistent here. Nobody, not me, not Knuth, not Fowler, is avocating stupid programming. Yes, you should be a master of algorithms, and yes, you should design so that later optimization is possible. But that shouldn't get in the way of writing clear, readable code except when you have the numbers to prove that performance is a real-world issue.
And I will assert boldly that most of the optimization people do without profiling first is just a waste of money. I've never had to throw out inherited code just because it was too slow. Instead, the stuff I chuck is because it's too big a pain to work on.
It sounds to me like this is just another way of designing, but that makes the wrong emphasis. These tests sound a lot like low level use-cases. You should be creating those anyways. But you should create all of those first! Not one at a time as you code.
Should? What, because it was written on the back of the stone tablets that Moses brought down?
Hi, I've tried it both ways. Test-driven design and refactoring work. It's possible to build good software both ways. In my opinion, TDD and refactoring are more productive and more fun. But hey, you're welcome to stick with your stone tablets if you want.
Requirements are the Achilles heel of XP. Without rock solid requirements, you are just guessing for the test scripts.
Spoken like a guy who has never done XP.
One of the core requirements of XP is known as the On-site Customer. This means that there should be somebody at all the meetings and sitting within shouting distance of the programmers, somebody who can answer questions like that or find out the answers. (In some companies this person is called a Product Manager; in others a Business Analyst).
I could only dream for mediocre requirements
Yes, requirements documents are generally silly. That's why XP doesn't use them. Instead of waving around some phone-book sized pile of garbage, XP practitioners use high-bandwidth, low-latency communications techniques: they talk. And they try out new versions of the software every week.
At least enough to try and read their minds.
Yep! And get yelled at when it turns out you don't have psychic powers. 'Cause that's what it takes to make standard development practices work. Isn't that a sign we should try something different?