ThoughtWorks developed one of the largest Rails applications in the world for a client called OVE.com. They started with 2 developer pairs and grew to 11 pairs plus other roles like business analysts over time. They learned that responsiveness to business needs is more important than technology choices, and that demonstrating work trumps arguments. They also automated testing, deployments, and other processes to help scale the large codebase and team.

1. ThoughtWorks
Rails in the Large:
Building the Biggest (Enterprise)
Rails Application in the World
PAUL GROSS software developer / consultant NEAL FORD software architect / meme wrangler
ThoughtWorks ThoughtWorks
nford@thoughtworks.com
pgross@thoughtworks.com 3003 Summit Boulevard, Atlanta, GA 30319
200 E. Randolph St, 25th Floor, Chicago, IL 60601-6501 www.nealford.com
pgross@thoughtworks.com www.thoughtworks.com
www.pgrs.net blog: memeagora.blogspot.com
www.thoughtworks.com twitter: neal4d

2. coming RSN

3. metrics
feedback
loops
automation
time & space
demonstration
communication
non-
intuitivity

4. what OVE.com does

7. the pursuit
Go for the one that’ll beat the
one that’ll beat the one you
last did

8. .NET Rails

10. quick start: october 2006
Project manager Business Analyst
Tech Lead Developer

11. inception: Jan 17, 2007
Started with 2 pairs
Added one pair every 2 weeks
8 or 9 pairs by July

12. now
11 pairs of developers 8 business analysts
iteration manager
client principle
6 quality assurance project manager

13. lessons learned
technology isn’t as important as responsiveness
to business needs
don’t try to convince too early
spikes are your friends!
demonstration over arguments

14. infrastructure
Rock is for Rookies:
males have a
tendency to lead
with Rock on their
opening throw

15. physical infrastructure
BA
standalone QA
integrated QA
pairing workstations
UAT
(sneak peak)
XServe (Selenium Grid)

16. deployment stack
10 web boxes 2 image servers
4 database
servers
background server memcache

17. technical stats
feedback
loops

18. environment

20. lessons learned
scale infrastructure opportunistically...
...but don’t wait too long
Mac OS X rocks
have fun

21. testing
Scissors on First:
play scissors as your
opening move against a
more experienced player

22. disconnected unit tests
UnitRecord and the evolution of unit
tests that don’t hit the database
http://github.com/dan-manges/unit-record

23. unit tests

24. the rule:
unit tests don’t hit the
database
mock everything

25. functional tests

26. no mocking allowed in
functional tests
tests that hit the database are
slooooow

27. feedback
loops
DeepTest
http://github.com/qxjit/deep-test

29. metrics
automation time & space
DistributedDeepTest
demonstration
non-
intuitivity

30. Selenium grid
time & space

31. lessons learned
fight the battle to keep tests fast
invent stuff if you have to
write smart tests
scale development infrastructure just like
production infrastructure

32. knowledge transfer
Paper is the least obvious
of opening moves.

33. project Mingle on the
wall

34. cc_board
http://github.com/qxjit/cc_board/

35. play a song when a
build breaks
communication
play theme song upon
successful checkin

36. jukebox.rb
currently in alpha
http://subversion.hammersforge.com/
jukebox.rb/trunk/

37. pairing stations
adium
no email

38. internal Jabber server
chat rooms
devs
BAs
QAs
shared buddy list

39. automatically set pair
name
adium
Mingle card (upon commit)

40. feedback
lessons learned
loops
software is more about communication than
technology
use information radiators
co-location rocks
communication
pairing really rocks
have fun

41. automate
everything
When playing with
someone who is not
experienced at the RPS,
look out for double runs
or, in other words, the
same throw twice.

42. 1-click deploy to any
environment
using cc.rb as easy deployment
tool

43. rake commit
run all unit tests
run all functional tests
verification (language keys)
commit
http://github.com/pgr0ss/rake_commit_tasks

44. canonical pairing station
maintenance
cap pairing_stations

45. radmind
http://rsug.itd.umich.edu/software/radmind/

46. strict rules for
advanced
language
features
Tell your opponent
what you are going to
throw and then actually
throw what you said.

47. Try playing the throw that would have
lost to your opponents last throw
background processing

48. evolution
of
asynchronous
messaging

49. progress bars &
async upload
backgrounDrb
http://backgroundrb.rubyforge.org/

50. 3 kinds

51. use backgroundrb for
simple message queue
backed by database

52. (Starling)
switch to a real
messaging queue

53. don’t know what we don’t know
“buy the fanciest one we
can” (just in case)
project time

54. technical debt
when you when you
add it start using it
project time

55. don’t know what we don’t know
“buy the fanciest one we
can” (just in case)
pay $$$ for technical debt…
…that you may never justify
project time

56. trying to predict the
future leads to over-
engineering

57. lessons learned
avoid anticipatory design
gradually add complexity
don’t use databases as message queues (for too
long anyway)
DBA’s can sometimes get grumpy

58. performance &
optimization
When all else fails, go with paper: Statistically, in competition play, it
has been observed that scissors is thrown the least often.

59. not that many page
views...
...really complex pages!

60. daily web trends

61. monthly web trends

62. why all the
rochambeau stuff?

63. view builds are fragile =>
separate cc.rb build =>
view builds are slow =>
1 pair assigned as view
masters

64. worst...job...ever

65. today’s view master
assigned by
yesterday’s...
...or play RPS

66. http://www.worldrps.com/

67. ThoughtWorks
?’s
This work is licensed under the Creative Commons
Attribution-Share Alike 3.0 License.
http://creativecommons.org/licenses/by-sa/3.0/us/
PAUL GROSS software developer / consultant NEAL FORD software architect / meme wrangler
ThoughtWorks ThoughtWorks
nford@thoughtworks.com
pgross@thoughtworks.com 3003 Summit Boulevard, Atlanta, GA 30319
200 E. Randolph St, 25th Floor, Chicago, IL 60601-6501 www.nealford.com
pgross@thoughtworks.com www.thoughtworks.com
www.pgrs.net blog: memeagora.blogspot.com
www.thoughtworks.com twitter: neal4d

68. metrics
feedback
loops
automation
time & space
demonstration
communication
non-
intuitivity