We're not strictly an Agile shop, actually, but thanks. On Mon, Apr 13, 2009 at 18:16, James Deville <james.devi...@gmail.com> wrote: > Another point. If you are fundamentally agile, you should have stories and > iterations. What if you posted current breaking change stories at the start > of the iteration before you started them. Assuming a 1 or 2 week iteration, > we get time to comment, and you won't have to hold code back. > JD > > On Sat, Apr 11, 2009 at 1:19 PM, Abraham Williams <4bra...@gmail.com> wrote: >> >> If versioning is used how long should versions be supported? A week? A >> month? Lets just say a month for now. If Twitter pushes out changes every 2 >> days it is possible that there would be 15 versions running at any given >> time. This is an extreme example but something to think about. >> >> On Sat, Apr 11, 2009 at 13:56, Alex Payne <a...@twitter.com> wrote: >>> >>> Right now, every new machine we get goes immediately into production. >>> Once we have enough machines that we can get ahead of that capacity >>> planning, I think a "beta.api.twitter.com" is a great idea. And/or >>> versioning. >>> >>> On Sat, Apr 11, 2009 at 11:00, Yu-Shan Fung <ambivale...@gmail.com> >>> wrote: >>> > I second Jesse's suggestion. Having a staging server to test out API >>> > changes >>> > would help smooth out transitions (though people needs to be careful >>> > about >>> > what change they make as presumably this will run against prod >>> > database). >>> > That way your internal developers can directly push code ready for >>> > release >>> > immediately to staging instead of waiting 5 days. >>> > It'll probably also help sanity internally at Twitter. Who knows, with >>> > developers hitting the staging API before it goes out, we might even >>> > help >>> > catch a bug or two once in a while before it goes out :-) >>> > Yu-Shan >>> > >>> > On Sat, Apr 11, 2009 at 2:21 AM, Jesse Stay <jesses...@gmail.com> >>> > wrote: >>> >> >>> >> Doug, can you guys do what Facebook is doing, and release it on a beta >>> >> server somewhere beforehand so we can test it on our apps before you >>> >> actually release it to the public? A public staging server of some >>> >> sort. >>> >> That will keep these surprises from happening, and we can start >>> >> working out >>> >> alerts to have in place when things might break our code that go on >>> >> that >>> >> beta server. Best of all, it won't ever affect the end user. Keep >>> >> the >>> >> releases on that server, then the releases out to the public on a >>> >> timed >>> >> release schedule. It might take a little longer to get out to the >>> >> public, >>> >> but you'll have a much happier developer base and in turn a much >>> >> happier end >>> >> user by doing so. That would be my number one suggestion. >>> >> >>> >> >>> >> >>> >> Do you guys do any tracking of Twitter itself for developers >>> >> complaining >>> >> about the API? I would also think you could gain some insight from >>> >> that as >>> >> well. >>> >> @Jesse >>> >> >>> >> >>> >> On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams <d...@twitter.com> >>> >> wrote: >>> >>> >>> >>> Twitter's development model is pragmatically agile where features >>> >>> enter >>> >>> the code base right alongside bug fixes. You can see this in our >>> >>> changelog >>> >>> [1]. What is not clear from the log is that most of the code is >>> >>> written just >>> >>> days before. >>> >>> >>> >>> April 8th's rapid deprecation of the since >>> >>> parameter/If-Modified-Since >>> >>> header (and to a lesser extent, the removal of undocumented HTTP POST >>> >>> access >>> >>> to accounts/verify_credentials) [5] caught a number of developers off >>> >>> guard. >>> >>> The criticism of this hasty change on the impact to hackers and >>> >>> businesses >>> >>> alike was both valid and appropriate. The results from last month's >>> >>> survey >>> >>> [6] lead us to believe that the use of this parameter was minimal and >>> >>> that >>> >>> it was safe to capture performance gains through the deprecation. In >>> >>> hindsight, our sample size was statistically insignificant because we >>> >>> made a >>> >>> mistake. >>> >>> >>> >>> It is apparent we need to make a change towards transparency. >>> >>> Openness >>> >>> demands we give developers a clear line of communication when changes >>> >>> are >>> >>> made that will break current functionality. While these changes are >>> >>> rare, >>> >>> they do happen. As a result of this week's conversation, we will give >>> >>> a >>> >>> minimum of 5 business days notice before we ship code that removes >>> >>> currently >>> >>> documented functionality. Two notable exceptions are critical >>> >>> security and >>> >>> performance fixes. >>> >>> >>> >>> Five days may seem short notice but it is a compromise from our >>> >>> standard. >>> >>> There are two major concerns we must consider when shelving code that >>> >>> is >>> >>> ready for deploy: >>> >>> 1) We do not write unnecessary code. Code only exists in the deploy >>> >>> pipeline for a feature or defect fix that is ready to go out the >>> >>> door. We >>> >>> view deployable code as an asset that should be handling requests as >>> >>> quickly >>> >>> as possible. >>> >>> 2) Un-merged code adds complexity. The Twitter code base is >>> >>> constantly >>> >>> moving. Deploying code requires merging with the master branch which >>> >>> grows >>> >>> in complexity as an undeployed branch sits idle. >>> >>> >>> >>> We currently use the changelog [1], @twitterapi [2], The API Announce >>> >>> List [3], and the Dev Group [4] to inform developers of changes in >>> >>> hopes >>> >>> that features will get used, and deprecations will be honored. I'd >>> >>> suggest >>> >>> any developer with a long-running application to subscribe to the low >>> >>> noise, >>> >>> only signal, API Announce mailing-list [3] to receive API updates as >>> >>> they >>> >>> are released. >>> >>> >>> >>> Lastly, lets work together. Tell me what you developers need that we >>> >>> are >>> >>> not currently providing. How can we better manage this communication? >>> >>> Which >>> >>> method of notifications work best for you? Aside from transparency >>> >>> with API >>> >>> changes, what else do you want to know? >>> >>> >>> >>> 1. http://apiwiki.twitter.com/REST+API+Changelog >>> >>> 2. http://twitter.com/twitterapi >>> >>> 3. http://groups.google.com/group/twitter-api-announce?hl=en >>> >>> 4. http://groups.google.com/group/twitter-development-talk >>> >>> 5. >>> >>> >>> >>> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/5822fbfd5ea857c6?hl=en >>> >>> 6. >>> >>> >>> >>> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/68f2667f4e9842aa?hl=en# >>> >>> >>> >>> Keep the bytes flying, >>> >>> Doug Williams >>> >>> Twitter API Support >>> >>> http://twitter.com/dougw >>> >>> >>> >>> >>> >> >>> > >>> > >>> > >>> > -- >>> > “When nothing seems to help, I go look at a stonecutter hammering away >>> > at >>> > his rock perhaps a hundred times without as much as a crack showing in >>> > it. >>> > Yet at the hundred and first blow it will split in two, and I know it >>> > was >>> > not that blow that did it, but all that had gone before.” — Jacob Riis >>> > >>> >>> >>> >>> -- >>> Alex Payne - API Lead, Twitter, Inc. >>> http://twitter.com/al3x >> >> >> >> -- >> Abraham Williams | http://the.hackerconundrum.com >> Hacker | http://abrah.am | http://twitter.com/abraham >> Web608 | Community Evangelist | http://web608.org >> This email is: [ ] blogable [x] ask first [ ] private. >> Sent from Madison, Wisconsin, United States >
-- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
