Extreme Programming For Platform Software

I'm unconvinced of ExtremeProgramming's utility when it comes to the design and construction of platforms for other software (e.g. programming languages, frameworks, message protocols, library APIs, operating systems, security models, concurrency models, etc.) - too often, the need to maintain backwards compatibility, especially to support the 'quirks' and 'bugs' of previous modes, quickly becomes an enormous burden against any attempt to RefactorMercilessly. However, I think it works fine for situations where the programmers DO possess full authority to muck around with all code and repair any dependencies broken as a consequence of refactoring. BigDesignUpFront vs YagNi, ProgramInTheFutureTense vs DoTheSimplestThingThatCouldPossiblyWork - I believe that each have their place in design and construction of software.

What if you codify those backwards compatibility 'quirks' and 'bugs' as automated acceptance tests? Then, the programmers will automatically continue to support the quirky interface. When the programmers want to change the interface, they submit a new story. The customer either schedules it for implementation or not, depending on his needs.

Ah, so your answer is: "That's not a bug! That's a feature!"

• Actually, you said that you need to maintain backward compatibility with bugs and quirks. I (pretending to be a programmer following XP practices) simply suggested automating a test for a requirement that you implicitly expressed.
• And I, pretending to be a user, looked at your unit-tests and found proof that you're guaranteeing your bug has a cozy little nest. ^_^
• You are the one who specified that that "bug" had to be there in the first place. An XPer will happily code in "bugs" as long as that is what you, as a customer, want. By definition, if you, the customer, want it, it is not a bug, at least to the programmer. So, what is it, do you, or don't you, want this point of compatibility in the future releases product? You, as the customer, makes that decision. --SamuelFalvo?
• Uh, no, the bug didn't have to be there in the first place. It shouldn't have been there in the first place. But, since your product is a platform for my code, and it has been deployed with a bug, I had to write my code to counterbalance the bug. I, as the customer, want: (a) a good platform with an intuitive interface that simplifies my own projects, and (b) for you to never break MY code, even as you continue to add features. If you're going to accomplish (b) you'll need to either maintain the bug (or poorly factored interface, etc.) or not deploy that bug/interface in the first place. Either mechanism is valid. I stated skepticism for XP's value in platform projects because it encourages a rapid-deployment cycle with simplistic initial structure to-be-fixed-later with merciless refactoring, all of which have consequences contrary to the customer goals.
• True, the bug didn't have to be there in the first place. But it was, GetOverIt. People are fallible, and you're just gonna hafta get used to it. However, odds are quite likely, you and two bazillion other people had to counter-code around the bug, which means if I fix that bug, I can introduce an incompatibility that will break a bazillion installations. The requirements analyst/project manager is responsible for interacting with the public such that, if fixing that bug were truly a priority, so high that breaking backward compatibility were permissible, then fine, we XPers will be more than happy to oblige. In fact, we WANT to oblige, because it means less work for us, our testers, and our technical writers. But if the payoff for fixing said bug involves more pain than benefit, then we just have to grin and bear it. That's life. --SamuelFalvo?
• Your argument still doesn't do anything to counter my cause for skepticism. It's as though your arguing: "We know accidents will happen. That's life. GetOverIt. In fact, since we do know accidents will happen, and can't be avoided, let's choose a methodology that will do its very best to guarantee as many accidents as possible!" Err... you XPers sure are excited, but no thanks? I won't argue that BDUF can cure all ills, but BDUF can easily take care of the readily predicted cases - i.e. those known from historical projects with similar properties that you'll almost assuredly encounter again with the myopic and forgetful XP (those who don't learn from history are doomed to repeat it). BDUF can also start with the assumption that the interface is poorly factored and the implementation is buggy, which will lead towards up front design of an upgrade-path that handles many classes of anticipated changes (potentially including anticipated changes to the upgrade path, for full symmetry). Indeed, the same problem can be attacked from both sides to get a solution that is both closer to correct to start with and less likely to suffer when upgrading. And if BDUF can help here, where XP promises a great many generations of poorly factored legacy code with a stoic 'that's life' grin, why shouldn't I be skeptical of XP for platform projects?
  • Please do be skeptical. I'm interested to know whether XP techniques would work for platform projects as well (we do a number of such platforms internal to our company). Mainly, I'm just suggesting XP-ish solutions to your objections until we either find something that can't (or probably won't) work, or you run out of objections.
• XP does not say that your first iterations of the interface have to be distributed to a bazillion customers. You can alpha test a few iterations yourself, and then have 3 or 4 beta testers who are willing to put up with a changing interface. After that, it should be much more stable.
• Yes, going through several development iterations with a closed group of people willing to break and repair their code would help on stability, especially if the products they wish to build on your platform are representative of those produced by the bazillion-customers. I'd recommend this even with BDUF (EatYourOwnDogFood is an idea that applies more broadly than any single methodology), but the requirement will be even greater for XP due to needing more generations or refactoring to get it right (as YagNi and DoTheSimplestThingThatCouldPossiblyWork forbid use of experience and foresight in making decisions).
  • YagNi and DTSTTCPW do not forbid use of experience and foresight. YagNi simply forbids speculative development of things you don't need yet (i.e. creating interfaces and capabilities that the customer didn't ask for). This would seem to actually be helpful in keeping speculative stuff out of the interface, thus reducing the amount of backward compatibility required. DTSTTCPW also does not force you to do stupid things that won't work. If your experience and/or foresight says something can't work, then do something else.
    • All use of foresight is speculative and about things that you don't immediately require. DTSTTCPW does allow you to avoid things you know won't work, but also forbids you from doing something 'slightly more complex' that you forsee yourself needing in the future.

• You're free to be skeptical, but you're not free to make false associations and pass them off as facts. Please demonstrate how XP advocates these so-called accidents. XPers accept reality. Yes, accidents do happen. But we mitigate them, not encourage them. --SamuelFalvo?
• Platform interface stability is a goal for platform users. The 'DoTheSimplestThingThatCouldPossiblyWork' greedy-heuristic approach along with the myopic 'YagNi' will create simplistic platform interfaces that solve the jobs immediately at hand but that are very likely to be changed in the future - especially in those cases where history or a little foresight would prove that YouAreGonnaNeedIt.
  • This is where the customer applies his foresight, and says he needs it. If the customer says he needs the interface to be X, then it is by definition needed.
    • Ah, so customers are to be the experts in software design and to synthesize all UserStorys (including platform-upgrade stories) into a near-correct interface on their own steam. Sweet. That really takes the onus off you XP programmers. Maybe I should ask my customers how to do my job, too. ;) BigDesignUpFront DesignByCommittee, here we come!
    • Can we use our heads here? Please? Just once? If a customer says, "I want version 3.0 to be compatible with version 2.0," then clearly, patently, obviously that is a customer requirement. We already know what "to be compatible with version 2.0" means. We either already have the 2.0 requirements encoded in unit/acceptance tests, or it's easy enough to make them. Where, in that requirement, does that make the customer experts in software design? That is OUR job. The customer, however, is a domain-expert in what he wants. How would you feel you called me up, and said, "Sam, I need a program that is compatible with Apache's CGI interface, so I can use it on my website," and I turned around and said, "You're full of brown it. I'm building this thing to MY specifications, because CGI is bum-effing stupid." You'd probably take your money elsewhere. And, as a customer, you probably should. So, stop jumping to STUPID conclusions, and I mean STUPID -- they're SO outlandish, SO ... STUPID that they defy explanation! Else, I will delete everything you write on the grounds of it being pure hyperbole. Either think things through, give credible evidence and not total heresay to support your claims, or just don't say anything at all. Really. --SamuelFalvo?
    • I am using my head, but I feel you are looking at only half the picture - you've latched too heavily onto the compatibility issue. Customers want backwards compatibility regardless of whether the original interface is good or bad, but they also want a good, well-factored interface - the sort of thing you'd get if the system was designed by experts with a lot of experience and foresight, without all the confusing cruft or legacy quirks. While I have acknowledged that XP allows for keeping a stable interface, you have failed to acknowledge or even offer consideration to the quality of that interface - i.e. you've been completely ignoring the heart of my skepticism. XP's use of YagNi and DTSTTCPW is really good at creating simplistic and (in the long run) poorly-factored interfaces and getting them into production really fast. XP's use of unit tests is really good at keeping a poorly-factored interface very stable. XP's use of RefactorMercilessly to factor your poorly-factored interfaces into good interfaces is essentially blocked, hitting a rather massive wall in the form of backwards-compatibility requirements. And thus my skepticism: XP will produce a great deal more garbage that you need to carry from one version to another when given the same customer requirements than would more traditional methodologies - or at least this is what my reasoning, intuition, and bits of experience in the platform software field tell me. If you're not convinced by my reasoning, that's fine, but I'd appreciate you holding off on calling 'stupid' my reasoning before you've identified for me my fallacy or invalid assumptions.
      • Thank you for the clarification. However, we must agree to disagree completely. I can see how XP might lead to this, but, I wager that this would happen with any group of neophyte developers, regardless of design methodology. In fact, your above-mentioned concerns proved to be the driving factor behind the codification of extreme programming, as folks who use Waterfall model tended to produce such crufty software as you describe. How do you feel about ScrumMethod? and/or SpiralMethod?? --SamuelFalvo?
      • I submit that the nature of XP suggests the issues I name are regardless of whether the people writing the code are neophytes or experts... because XP's tenets (YagNi, DTSTTCPW) prevent application of this expertise. If you use foresight or experience beyond figuring out what can't possibly work, you aren't adhering to XP - not as the methodology is proudly described on WardsWiki. As far as "agreeing to disagree completely" - you're free to disagree, and I'm free to remain skeptical, but since you've never offered reasons for your strong objections I'm left feeling like I've stepped on some 'holy ground to never be questioned' by SamuelFalvo? and his church-of-XP. And I do not know ScrumMethod? or SpiralMethod? well enough to offer an opinion, and only recollect a vague distaste for Waterfall model (it's been too many years since I learned about it). By 'traditional' methodologies, I mean old-school: think-then-do, taking advantage of experience and foresight and a thorough education of failures seen in similar previous projects, seems to be better than XP for purposes of getting high quality platforms. It seems to me that ALL 'great' software platforms were created this way, be they programming languages (e.g. lisp), data models (e.g. relational model), concurrency models (e.g. actor model), programmable editors (e.g. emacs), shells (e.g. bash), etc.
      • I submit that XP delivers on its promises. I have first-hand experience working with XP. I also have first-hand experiences working with Scrum (in my current job, in fact, we use Scrum). Both deliver on their promises. No, they're not silver bullets, they do not replace the necessity for experience, but they work. In fact, nothing replaces the need for experience. Nothing in XP says you don't ever think. Nothing. Quite the opposite -- when implementing a user-story, you basically go through a microscopic waterfall process -- break the story into engineering tasks, analyze the tasks for testability (output: unit tests), implement the core logic to make said unit tests pass, and finally perform integration testing via continous build/testing. The phases are all there. The granularity of the phases, however, are much smaller. Instead of thinking up all requirements for an entire project, then analyzing the entire body of requirements, then coding everything in one fell swoop, then testing it all, we do things piece by piece. You openly admit to having little experience with XP, Scrum, et. al. -- you're perfectly within your right to be skeptical of their claims. But, I have first-hand experience. I know what it can do. I don't need a church of XP. There is no blind faith here. --SamuelFalvo?
      • "Nothing in XP says you don't ever think. Nothing." - DTSTTCPW says "don't think about more complex alternatives".
        • No it doesn't. It says you need to apply OccamsRazor towards achieving a goal.
          • Sure, but not towards achieving your goals - plural. I.e. "don't think about solutions that will solve more than just the one problem you're myopically targeting at this very moment"
      • Dealing with one user-story at a time says "don't look at the big picture".
        • No it doesn't. It says you only work on one aspect of the project at a time. Remember you likely will have other codevelopers who are working on other user stories at the same time! Also, the XP system metaphor helps put things into context at a larger, more human, scale.
      • A bunch of individual codevelopers working on different user stories just means a bunch of myopic people not designing for the big picture.
        • Everyone has the big picture, courtesy of regular stand-up meetings (often daily, particularly in the Scrum process).
      • XP says "don't think in certain ways" which is, indeed, a way of saying "don't think".
        • Hmmm, not sure where this came from. I've never seen this in any XP manifesto, book, video, or conference. I think you're jumping to conclusions.
      • I think I'm jumping to the obvious and correct conclusions.
        • Where is your hard evidence to support your claims? Without that, the entire logical framework leading up to your "obvious" conclusions are wholesale without merit and legitimacy.
          • Don't be a hypocrite - I don't require "hard evidence" to support my skepticism, and you OBVIOUSLY don't need it to support your beliefs. There haven't been any rigorous tests to provide "hard evidence" for any of the software programming methodologies, including the ones you favor. Reasoning and experience have been and will need to remain sufficient for both of us. And I've provided my reasoning based on the underlying principles of XP. Where's yours? Am I arguing with someone who takes XP manifestos as gospel truth and only demands hard evidence when faced with a skeptic?
      • If any methodology says: "think this way", it's equivalent to saying, "and don't think in this contradictory way".
        • E V E R Y methodology says, "Think this way!" Let me repeat this, because it bears repeating: E V E R Y methodology says, "Think this way!" Otherwise, it wouldn't be a methodology!
      • XP just happens to prefer a certain sort of myopic, think about the now, never ProgramInTheFutureTense approach.
        • What do you think we do during our stand-up and scrum meetings then? Play NintendoWii? while mocking our customers? As far as I am concerned, this conversation is utterly finished. You have yet to provide one shred of credible evidence to support your claims. You make wild and patently false generalizations about a process you ADMIT to knowing nothing about. If you wish to continue this discussion in any meaningful manner, get a job in an XP shop, gain a year or two experience, and then we can talk. I'm not trying to be rude here, just honest. Trust me, the more you continue on this tyrade against XP without hard evidence to back your claims, the more of an ignoramus you make yourself out to be. --SamuelFalvo?
          • I've offered reasons for my opinion, and the most you've done to argue against it is rant and rave with B I G letters. I must say I'd respect reasoning quite a bit more.
      • The small granularity requires the later big refactorings - depends on it to clean up the design flaws that working on such a myopic scale produces.
        • RefactorMercilessly alleviates this to a significant effect. Major refactorings are infrequent enough to justify their expense. It's the age-old application of the EightyTwentyRule. Contrast this with the BDUF approach you advocate, where you need total rewrites almost as often as you get paid, as that's about how often the customer's requirements change. I've had first-hand experience with this too. A dental application I was working on as one of my first programming assignments many moons ago -- the team I was part of had to rewrite the thing three times before a final delivery to the customer was made. Very frustrating.
          • I agree. RefactorMercilessly works. It does exactly what it is advertised to do. But it also has certain requirements before you can do it - if it is blocked due to requirements to maintain backwards compatibility, you're pretty much hosed. The cause of my skepticism is that RefactorMercilessly is blocked very commonly in the development of platform software - in particular at the interface layer. And I'd never recommend BDUF where RefactorMercilessly is cheaply available. Where it is impractical, OTOH, due to constraints on how you can change the project's interface or code-freezes or issues of code ownership, etc. - refactoring can be much more expensive than scrapping the project and starting again from scratch.
      • Maybe XP does "deliver on its promises" - but if that is the case, then I expect it must not be promising much about the final quality of platform software under constraints of backwards compatibility across iterations. I don't doubt your experience with XP, but I am feeling some doubt regarding your experience with XP as specifically applied towards the domain described by this page's topic - ExtremeProgrammingForPlatformSoftware, or even software platforms in general.
        • You mean, like the project I'm working on now? OK, we're not using XP as such, but we are using Scrum with a lot of TestDrivenDevelopment -- the only thing needed to make this work fully XP would be the adoption of pair programming. --SamuelFalvo?

    • As far as customer expertise: the customer can offer and prioritize UserStories and UseCases, and come up with new stories and cases as you get things implemented, but rarely can specify an interface - that is (in my experience) most often part of your job, along with documenting the changes and teaching them how to 'do X' with the new interface - i.e. "user needs to do X; how do I modify the interface so the user can do X?". If they did do their own BDUF or grab a third-party standard and give you an exact interface, then that particular interface would be a requirement. But that situation is not general or even particularly common - not until multiple businesses start sitting down in committees to do some big design up front. And sure, if a customer wished to replace the Apache WebServer platform, the need to obtain compatibility with Apache's CGI and related (e.g. '.httpd') support would constitute critical UseCases. However, if you're talking about writing up a CGI program for the Apache WebServer, that wouldn't, in the general case, even qualify as a software platform product (since external customers aren't running code on top of most CGIs).

• XP, as a methodology, counterbalances the deficiencies of YagNi and DTSTTCPW by use of another of its tenets: RefactorMercilessly, embrace change, fix the interface when the need is apparent. Fundamentally, this has two assumptions: (a) the 'need' to fix things will become apparent to someone with the immediate power to make changes, and (b) you have the power to repair code that breaks after you start refactoring. Fundamentally, both of these assumptions are violated by bazillion-user platform software: (a) is violated because you aren't the guy writing most of the code running atop your platform (and thus you can't readily see which patterns need to be refactored into the interface), and (b) is violated because you aren't a guy with write-access (or even read-access) to most of the code running on your platform. So you can't RefactorMercilessly AND (simultaneously) maintain platform stability, and you often can't even know when you should RefactorMercilessly. Though, as mentioned above, sufficiently representative use of EatYourOwnDogFood and using closeted beta-tests can help a lot.
  • It seems like we have a basic misunderstanding here. For a platform project, the definition of the interface is a requirement. It is therefore not a candidate for the development team to change or refactor any more than any other project's requirements. The customer specifies the interface, and the development team uses XP to implement the requirements.
  • It would seem to follow that the interface is designed up front and has a high cost of change. This might apply when implementing a third-party standard, but for other cases it doesn't seem very XP.
  • Interface design and high cost of change are a domain issue for platform software in much the same way that vacation policies are a domain issue in a payroll system. You wouldn't expect the XP developers to "refactor" vacation policies, and neither should you expect them to "refactor" your domain issues. The person in the role of the customer has to make decisions regarding domain issues and therefore has to be knowledgeable about the domain. In the case of platform software, this would mean deciding such issues as consistent interface design and interface evolution strategies. Regardless of methodology, unless the person in control of the requirements is a domain expert, you are doomed to create a crappy product.
  • I.e. BDUF is needed, and XP demands the customer do it, and further XP can't take much advantage of its 'agile' continuous feature improvements, putting UserStories on cards, and receiving and rapid releases - if the collective customers change direction or repeatedly add extensions but demand backwards compatibility, they are doomed to a crappy product that forever reflects all these changes without possessing the refactoring to make it elegant and simple(at least not at the interface) - XP's RefactorMercilessly usually can eliminate the 'history' of a software product, but software platforms have the privilege of carrying it like baggage, forever. ExtremeProgrammingNotForSoftwarePlatforms? - at least not in the same way it is for GUI projects. But, if all the requirements really are known up front, by someone who knows when YouAreGonnaNeedIt, who can provide a complete vision or ProgramInTheFutureTense, then there is no reason to expect XP to fail - but it still doesn't seem very XP.

• I see XP only exacerbating (albeit not 'advocating') an already difficult problem in this case. Two of its core concepts (YagNi, DTSTTCPW) just make things worse, and its critical balancing tenet - RefactorMercilessly - hits two brick walls in the domain of software platforms. All it really offers are those UnitTests: the ones that help you guarantee your poorly factored interface remains just as poorly factored and quirky tomorrow as it is today. This is demonstrated logically, and I can assure you that it is entirely true in my own experience. How does SamuelFalvo? come to the belief that XP is 'mitigating' things here?

And it isn't just 'quirky interface', it's 'buggy consequences' for a 'correct' interface. E.g. consider a major vendor's web browser handling pixel placements - if stuff was off by, say, 7 pixels, then people start adding 7 pixels to reach their intended offset. And now you need to maintain this bug. You even put it into your acceptance tests. This is especially evil if the interface is specified by a standard somewhere. OTOH, if your goal is vendor lockin, you're well on your way to accomplishing that.

• For XP, all of the preceding is up to the customer to decide what he wants to do, after the programming team provides estimates for the various stories. XP admits that the programmers don't know how to decide what the product should do, and leaves it to the customer to decide in any manner he sees fit. XP can still be used to implement whatever the customer decides should be implemented.
• Do all XPers pretend there is always exactly one customer - 'the' customer? Should a new section be created that questions the value of XP for mass-market products?
• The "one customer" for mass-marketed software is known either as the ProjectManager or RequirementsAnalyst?, depending on how your organization is structured. --SamuelFalvo?

Combine this with a simple deprecation strategy -- automatically warn developers (both yours and your customer's) when they use a deprecated interface -- and the project would likely evolve into a "clean core", a "clean interface", and a "quirky deprecated interface". At some point, it may become apparent that it's time to document the "clean interface", drop some or all of the "quirky deprecated interface", and announce version 2.0.

Deprecation often sounds neat in theory but (given any sufficiently large user-base) it rarely works in practice, mostly because blaming the users for not forcing you to fix your bugs doesn't often work in practice. About the only thing you can do is upgrade versions entirely and either (a) hope you won't need to change again for a long time, or (b) provide an explicit mechanism to extend your own interface and maintain versioning compatibility directly into the project/language/framework/etc.. The latter option is not the most simplistic thing possible, and certainly requires a little BDUF, but can be quite simple and very elegant - I've seen it in some C and C++ libraries/frameworks (OneMoreLevelOfIndirection - e.g. asking for function-pointers by version-number and name), and I've seen it for various syntax systems (<?xml version="1.0"?>, syn, etc.), but even here the older interfaces remain 'baggage' that you can't eliminate and for which you probably ought maintain tests. Of course. That's what I suggest in the first place.

• There is also option (c) leave the deprecated interface items in place and tested for one major version cycle (in parallel to your new improved interface), and drop it after that (barring sufficient user requests to un-deprecate it). Ideally, you could warn / nag them about the use of deprecated interfaces on each compile / run. This seems to work fine for emacs.
• That might work well enough if your platform is a compiler or a system that is already designed to emit 'warnings' to someplace useful, otherwise you've just moved your BDUF someplace else: to the error and warnings logging system.
  • Don't most, if not all, platforms already have some sort of error/warning system already in place? Because of the nature of platform software, it seems that some sort of error/warning system would be beneficial to the users in almost every case anyway. It sure seems like it would help the end user solve problems using the platform.
  • No, most platforms do not have error/warning systems in place. Compilers generally do, and sometimes operating systems do, and a few languages have dedicated error output streams. But 'platform' also covers such things as message protocol designs, arbitrary languages and file formats, library APIs, object interfaces, frameworks, etc. - generically, interfaces exposed to users-who-are-also-programmers for further integration. Sometimes libraries or frameworks can take advantage of a compiler, so long as they are built in the same language as the code using them, but you can't count on it. Data languages and network message protocols are mostly a bust. Plenty of programming languages are also a bust - many just do something undefined then, often, crash hard. One thing I've learned after building many platforms is that error handling is a very difficult problem in the generic case, especially if you wish to be discerning about who (developer of platform, developer on platform, user of stuff developed on platform) sees how much, and doubly so if you wish to continue operations elegantly after error. (For most classes of error I'd advocate the sort of continuation-based exception handling described in AbortRetryIgnore, which happens to be the most powerful and generic approach to error handling that I've read about. But such things are really BDUF, even if all refactorings lead ultimately in that direction to the degree they are able.) A framework or language might build in the necessary features just to handle the special case of interface deprecation errors and warnings, but even then it needs a place to send these already built into the system.
• You can document this stuff in API (or, if warrented, even in user) documentation too. AmigaOs documentation, for years, gave warnings in their ROM Kernel reference manuals, to the effect of, "Use of undocumented features or things clearly marked as private are prone to changes in future releases of the OS, which can break your software. Resist the temptation to use them. But more importantly, do not blame us for incompatibilities with future OS releases if you do." Well, take a guess what happened when CommodoreAmiga? released AmigaOS 2.0? Some 80% or more of the software for the platform crashed hard, because nobody took Commodore seriously. Nobody got bent out of shape over this though -- within months, new, 2.0-specific versions of said software were on the market, and people upgraded in droves. Fortunately, afterwards, most vendors learned their lesson, and subsequent OS updates were substantially more smooth. --SamuelFalvo?

Seeking a 'good enough' refactored interface by use of throwing old ones away gets you to a decent position after a few or several versions (depending on the complexity of the product). However, the need to avoid breaking things never quite goes away - it always remains a constraint forcing you to take great care at the edges of your project whenever you feel the urge to RefactorMercilessly. That makes it rather difficult to be 'merciless'.

• Thus, the suggestion to add automated tests -- TestEverythingThatCouldPossiblyBreak.
• Such tests will let you know when you break something, but they're actually there to prevent you from refactoring interface - mercilessly or otherwise.
• Agreed. From the customer's point of view, they prevent the developers from refactoring the interface. From the developer's point of view, they are there to help ensure meeting your requirement [of not changing the interface].

---

Claims by someone:

• If you broke the code, then you aren't refactoring. You are changing functionality.
  • Refactoring almost always breaks code. It then fixes that broken code back to the same functionality, but the code is almost invariably broken between the moments of initiating a refactoring and completing the same - even typing a few characters into a code-editor usually breaks that segment of code until you finish typing a complete statement. Refactoring is not an instantaneous process that goes from one working system to another working system with the same functionality. Since code is broken during the duration of refactoring, you cannot use a state of broken code to say that you 'aren't [in the process of] refactoring', or that you therefore must be '[in the process of] changing functionality'.
• Note: if you are changing the interface, then you are changing the functionality of the platform, and this is by definition not refactoring
  • The goal of changing an interface is often to make it easier to use, not to change functionality of the platform. If the set of activities you can effect through use of the interface remains the same, then the functionality has not changed.

---

It should be known that platform is a BuzzWord for "a bunch of stuff" like.. everything, and everything. The term is so overloaded it doesn't have any meaning any more. This page should rather be called ExtremeProgrammingSucks? or ExtremeProgrammingDiscussion? or ExtremeProgrammingDebate?.

Ah, it is Mr. EverythingIsa BuzzWord again.

No, platform has a specific meaning as I use it here: a software platform product is one intended for other users to interface with via construction of code that interfaces with the platform. The key word there is the 'other' in the 'other people' - as in, the platform itself is what you are selling. And GUIs don't count because, while they are interfaces, they aren't platforms for software. However, language standards and implementations do count - e.g. C language is a software platform; indeed, they might qualify as the 'pure' example since that's the only thing they do: accept code to run. But such things as frameworks (like Java Swing or MFC or readline) are also prototypical. Extensible and plugin systems like Mozilla Firefox and GIMP aren't quite as prototypical because they offer considerable initial user functionality, but they do qualify - at least for the interface they expose for these plugins and extensions.

• C language is not a platform - it is a language. An implementation of the C language such as a compiler, interpreter - might vaguely be described as a platform. Hence my argument that anything can be bent into being described as a platform. A girl, and a guy - are platforms to have sexual intercourse with. Sigh.

The basic consequence of software platforms is that their interfaces are basically impossible to refactor while keeping the software-platform customers happy (because a programmer whose code breaks is a very angry customer). You can add to the interfaces monotonically, but you can't perform any reductions or transformations. And adding to an interface is not at all the same as refactoring.

And as far as your page suggestions go: I'd have chosen 'ExtremeProgrammingNotForSoftwarePlatforms?'. I've used XPs tenets in other places, though, and must admit to some satisfaction with them. But, now that I think about it, it seems likely that ExtremeProgrammingNotForSoftwarePlatforms? is just a specific case of XP not really being for negatively stated constraints in general. I.e. "must never take more than N milliseconds to accomplish task X", "must never allocate memory from the free store after loading", "must never give my personal information to an unauthorized person",... "must not violate backwards compatibility" - backwards compatibility is, itself, a UserAntiStory.

Eclipse IDE is a platform, Mozilla is a platform, this wiki is a platform, Win32 is a platform, Ebay is a buyer/seller platform, C2 is a discussion and article platform, etc.

True. And you can't just muck around with certain parts of Eclipse or Mozilla or Win32 without breaking a lot of other people's code. But this wiki is not a software platform product - all the code (pages) on the wiki are owned by the wiki, and transformations are easily possible.

• You can't muck around with C2 software because the C2 platform serves people who will be ticked off if the C2 platform changes. If the syntax changes everyone will be up in a scurry trying to figure out why the C2 platform changed. If the C2 platform no longer produces HTML and only produces YAML or some other format, it will tick off many people and browser software. If the C2 software platform only allows certain people to edit the data then it will tick many people off. If the C2 software platform is updated to be better or worse, it may cause issues for browsers, people, software.

Since this wiki (c2) was written bottom up with extreme programming ideas in mind (bottom up content, do the simplest thing, etc) and since this wiki is a platform for lots of people... and since everything else including Emacs, EditPlus, and Internet Explorer are platforms - I call the day. I call BullshitBingo.

That's an invalid argument - premature generalization and assuming the antecedent. I wonder if there's a penalty for calling bingo without actually having it.

Your claims seem to be Extreme Programming cannot create platforms well... C2 wiki is a platform and it works. So extreme programming can work for creating platforms. Anyway, I'm no huge fan of extreme programming, but since this wiki was written by extreme programmers I have to have some respect.

C2 is not a software platform product. Your argument that "everything" is a platform for software is fallacious.

Your argument that C2 is not a software platform is fallacious. C2 is a platform for tens, hundreds, or thousands of people and software browsers/editors to connect to and utilize.

Which is, of course, entirely irrelevant. People aren't writing software to run on C2, therefore C2 is not a software platform. HTML is a software platform. HTTP is a software platform. C2 is not. Platform for people != Platform for software.

• HTML is not a software platform. HTML is a markup notation.
  • Those two things are not mutually exclusive. A great deal of software is built atop HTML and depends very heavily on its structure. It's part of the reason that HTML can't change very rapidly to meet user demands.
• C2 is a platform for software (browsers, thin clients, editors) to connect to - people happen to use browsers to connect to C2 wiki, but the C2 wiki platform talks with browser software and operating systems. C2 is also a platform for google and robots to connect to.
• If "platform for people <> platform for software" then operating systems (for people) are not platforms, nor are web browsers - since web browsers are for people - not for software. HTML is not software - it is just dumb text. A javascript interpreter, could be considered a platform - but HTML is just like an article. A wiki has markup just like HTML, therefore if one considers HTML some software for the browser, then one must consider C2 markup (like html but different) software food for the C2 wiki platform to eat too.
  • Netscape plugin systems and Gecko extensibility and its own personal brand of Javascript are what make Mozilla Firefox a software platform - not the GUI. Operating system APIs are a software platform too, though the user-interface is not.

Browser software connects to the C2 platform daily. C2 software is a surface and platform that serves people and other software (robots) text and data daily. C2 wiki is a surface and platform that can support hundreds of users running browser software. C2 platform has common platform rules and tools in the platform (such as syntax for wiki articles, find tools, url API, "diff" toolset, steward tools). A C2 wiki contains a framework, platform, base, in which humans reuse daily. Many web applications are platforms since they have a URL api and a common surface which people and software can connect to. Ebay can be considered a buyer and seller platform for people and software. C2 can be considered an article, discussion, and publishing software platform that runs in a web browser for web users and software. Platform platform platform. Ebay is a software platform that people can connect programs to. Every website could be described as a platform - with some being bigger platforms than others. An operating system could even be described as a people platform more so than a software platform - since mostly an operating system serves people. A CPU could be described as a platform which software runs. A browser could be described as a TCP/IP platform. Platform Platform Platform. Whatever a platform is.

---

XP can be very confusing when writing platform software if you're not careful. Let's take the specific example of an API. If you're using XP to write an API, then:

• Your onsite customer needs to be an experienced developer, the sort of person who can tell a good API from a bad one.
  • Said customer is not a member of your dev team. They are the customer, after all. Don't let them program the backing code.
  • On the other hand, the customer in this case will be very valuable because they can speak the dev team's language (perhaps even writing the API as a set of well-commented interfaces). They will also be able to write AcceptanceTests as unit testing code. Again, don't confuse the AcceptanceTests as the unit tests.
• The API that the customer defines is the set of user stories. The dev team is not allowed to change them. If the situation permits, configure your source control so that members of the dev team have no write permissions to the API itself.
• The deliverables are APIs that work as the customer defined them.
• There are two sorts of "bugs".
  • One is when calling the API produces a result other than what the customer wrote down. This is the same sort of bug handled by dev teams of every stripe. If one of these gets released, the customer needs to decide to ask the team to fix the bug (possibly breaking clients) or make that a documented and tested "feature" of the API
  • the other is when the API itself has a problem, is ambiguous, or has problems that make it hard to sell (think of the C gets() call--it's not broken due to a bad implementation, it's broken by specification). XP doesn't have an answer to this. XP repeatedly, thematically, and militantly disclaims responsibility for customer decisions. It gives the customer what they ask for, and hopes to give the customer what they want by making it easy for the customer to change his mind repeatedly. If the onsite customer (read: domain expert) wants something that won't make the company money, that's a business problem rather than a development problem.

It's less confusing when writing something like a financial package or a fluid dynamics simulator, because it's obvious that the CPA or areonautical engineer aren't the developers. Here, where the customer has similar skills, the temptation is to have the customer be a developer.

---

AprilZeroEight