History of the IntelliJ IDEA codebase and development practices used in its development.

1. From Renamer
Plugin to
Polyglot IDE
Dmitry Jemerov
CTO, JetBrains
Monday, September 9, 13

2. IntelliJ IDEA: 2000-2013
• Started as a plugin for JBuilder
• Currently a product line of 8 IDEs, a
compiler, a DSL workbench and a server-
side code browser
• $xxK initial investment, $yyyM total
revenue
• HEAD is a usable IDE every single day
Monday, September 9, 13

3. Agenda
• IntelliJ IDEA over the years
• IntelliJ IDEA development practices
Monday, September 9, 13

4. IntelliJ IDEA:
Over the Years
Monday, September 9, 13

5. 2000
• February 1st - company birthday
• Founded by Sergey Dmitriev, Eugene
Belyaev and Valentin Kipiatkov from
TogetherSoft
• IntelliJ Renamer, IntelliJ CodeSearch
Monday, September 9, 13

6. Monday, September 9, 13

7. Vista
1.0, Jan 2001
• PSI, VFS, commands
• Saved 2 months by not having plugin API
• Mentioned by Martin Fowler on
http://refactoring.com/
Monday, September 9, 13

8. Stella
2.0, June 2001
• First external developers
• JSP, CVS, Ant, formatter, live templates
Monday, September 9, 13

9. Pandora
2.5, Dec 2001
• 13 new refactorings
• JUnit integration, one unit test in code
• Released 1 month after Eclipse 1.0
Monday, September 9, 13

10. IDEA 2.6
June 2002
• Company renamed to JetBrains
• JOLT Award in April 2002
Monday, September 9, 13

11. Ariadna
3.0, Nov 2002
• OpenAPI,
• 2 plugins (open-source): Starteam,
Tomcat
• XML
• Real tests
• Oldest version available for download
Monday, September 9, 13

12. Fabrique
Monday, September 9, 13

13. Fabrique
• Framework and set of components for
developing Web applications
Monday, September 9, 13

14. Fabrique
• Framework and set of components for
developing Web applications
• Visual IDE based on top of IntelliJ IDEA
Monday, September 9, 13

15. Fabrique
• Framework and set of components for
developing Web applications
• Visual IDE based on top of IntelliJ IDEA
• Drove a lot of platform API changes
Monday, September 9, 13

16. Fabrique
• Framework and set of components for
developing Web applications
• Visual IDE based on top of IntelliJ IDEA
• Drove a lot of platform API changes
• Project view, structure view, extensions
Monday, September 9, 13

17. Fabrique
• Framework and set of components for
developing Web applications
• Visual IDE based on top of IntelliJ IDEA
• Drove a lot of platform API changes
• Project view, structure view, extensions
• Canceled in 2005 before reaching 1.0
Monday, September 9, 13

18. Monday, September 9, 13

19. ReSharper
• Started in mid-2003
• Implemented in C#, different architecture
• Initially used some parser/PSI technology
from IntelliJ IDEA
Monday, September 9, 13

20. Aurora
4.0, Feb 2004
• Multiple-module projects
• On-the-fly inspections
• UI Designer
Monday, September 9, 13

21. Pallada
4.5, July 2004
• J2EE
• First two community-developed plugins
• Inspection Gadgets
• Intention PowerPack
Monday, September 9, 13

22. Irida
5.0, Aug 2005
• Custom language API
• JavaScript, Python
• Perforce + Subversion, open-source
plugins
• 1M LOC
• 10 developers, no QA engineers
Monday, September 9, 13

23. Monday, September 9, 13

24. Demetra
6.0, Oct 2006
• Core and Enterprise subteams
• TeamCity 1.0
• First plugin contest
Monday, September 9, 13

25. Selena
7.0, Oct 2007
• New caching VFS implementation
• Facets
• Ruby, Groovy
Monday, September 9, 13

26. Diana
8.0, Nov 2008
• Java-independent IntelliJ Platform
extracted
• RubyMine 1.0 in April 2009
• Language-independent indices
• Language-independent debugger
Monday, September 9, 13

27. Community Edition
Oct 2009
• Moved to git
• ~ 60% of codebase open-sourced
• Expected 30% drop in sales, got small
gain
• Couple dozen external contributors
Monday, September 9, 13

28. Maia
9.0, Dec 2009
• Background indexing
• Artifacts
• PHP
Monday, September 9, 13

29. Idea X, Xena
10.0, Dec 2010; 10.5; Feb 2011
• Autopopup completion
• Android in Community Edition
• PhpStorm (May 2010), PyCharm (Oct 2010)
Monday, September 9, 13

30. Nika
11.0, Dec 2011
• UI redesign
• "core" package for Kotlin compiler
• AppCode (Oct 2011)
Monday, September 9, 13

31. Leda
12.0, Dec 2012
• Darcula
• External make
• UpSource, headless indexing framework
Monday, September 9, 13

32. Android Studio
May 2013
Monday, September 9, 13

33. Android Studio
May 2013
• Built by Google with support by JetBrains
Monday, September 9, 13

34. Android Studio
May 2013
• Built by Google with support by JetBrains
• Apache 2.0 licensed, no contracts and no
money involved
Monday, September 9, 13

35. Android Studio
May 2013
• Built by Google with support by JetBrains
• Apache 2.0 licensed, no contracts and no
money involved
• 500K downloads in first 3 weeks
Monday, September 9, 13

36. Cardea
Version 13, in development
Monday, September 9, 13

37. Cardea
Version 13, in development
• ~ 25 developers
Monday, September 9, 13

38. Cardea
Version 13, in development
• ~ 25 developers
• ~ 5.6M LOC, ~3M LOC open-source
Monday, September 9, 13

39. Cardea
Version 13, in development
• ~ 25 developers
• ~ 5.6M LOC, ~3M LOC open-source
• ~ 100K daily active users, 72% Ultimate
Monday, September 9, 13

40. Cardea
Version 13, in development
• ~ 25 developers
• ~ 5.6M LOC, ~3M LOC open-source
• ~ 100K daily active users, 72% Ultimate
• 50% Windows, 30% Mac, 20% Linux
Monday, September 9, 13

41. IntelliJ IDEA:
Development Practices
Monday, September 9, 13

42. Break the Rules
• No detailed planning
• No unit tests
• No QA
• No code comments or internal docs
• No API compatibility
• Many wheels reinvented
Monday, September 9, 13

43. Release Planning
Monday, September 9, 13

44. Release Planning
• Management sets only high-level goals
and target date
Monday, September 9, 13

45. Release Planning
• Management sets only high-level goals
and target date
• Each developer responsible for detailed
planning of their subsystem(s)
Monday, September 9, 13

46. Release Planning
• Management sets only high-level goals
and target date
• Each developer responsible for detailed
planning of their subsystem(s)
• No iteration planning
Monday, September 9, 13

47. Release Planning
• Management sets only high-level goals
and target date
• Each developer responsible for detailed
planning of their subsystem(s)
• No iteration planning
• No feature specifications
Monday, September 9, 13

48. Standup Meetings
• Daily, broken into sub-teams
• Over video conference between
St.Petersburg, Munich and Prague
• Allow management, QA and writers to
stay on top of dev activity
Monday, September 9, 13

49. Development Flow
• Everything done in master
• Almost no long-lived feature branches
• Branches used only for releases
• Refactorings in incremental steps
• New features side by side with existing
code, turned on by system property
Monday, September 9, 13

50. Automated Testing
• Mostly data-driven acceptance tests
• Code before, action to perform, code
after
• Few pure unit tests, little usage of mocks
• Test framework agnostic (JUnit, TestNG,
Cucumber)
Monday, September 9, 13

51. Continuous Integration
• Used TeamCity since day 0, CruiseControl
before that
• Remote run not mandatory but
recommended
Monday, September 9, 13

52. Testing: Upsides
• Easy to write
• Often just copy code example from bug
report
• Very little fragility when impl changes
• Tests written 8 years ago still valuable
Monday, September 9, 13

53. Testing: Downsides
• Whole test suite (37K tests) takes 7 hours
to run
• Multiple commits per test run
• Failures difficult to debug
• Especially async code (indexing, UI)
• Tests stay red for weeks
Monday, September 9, 13

54. Testers
• Had no testers until 2006
• Focus on manual testing and usability
• No "quality assurance" as such, relying
more on CI tests and user feedback
Monday, September 9, 13

55. update.bat
• Every developer starts their day with
building IntelliJ IDEA from latest sources
• "Do not update" emails if something
badly broken
• Core Java stuff always works
Monday, September 9, 13

56. Early Access Preview
• Public free-to-use builds released every
1-2 weeks
• Broad community testing for features we
don't use internally
• A few thousand active EAP users
• Licenses for most helpful participants
Monday, September 9, 13

57. Public Issue Tracker
• Initially ITN, then JIRA, then YouTrack
• ~ 50 new issues per day
• Low noise but many duplicates
• Triaging incoming issues – almost full-
time job
• Imbalance between developers
Monday, September 9, 13

58. Exception Analyzer
• Separate from issue tracker
• Reports grouped into problems
• Semiautomatic merging of duplicates
• Exception duty rotated between
developers, takes a few hours per day
Monday, September 9, 13

59. Code Review
• Previously used manual review (mostly
face-to-face) for merging into release
branches
• Now reviewing all platform changes
• Using Crucible and hating it
• Need tools to see context of change
Monday, September 9, 13

60. Support
Monday, September 9, 13

61. Support
• Until recently one support engineer
(Serge Baranov) was covering all IntelliJ
Platform-based IDEs
Monday, September 9, 13

62. Support
• Until recently one support engineer
(Serge Baranov) was covering all IntelliJ
Platform-based IDEs
• Best Technical Support (small to medium-sized
business, SD Magazine Reader's Choice 2005)
Monday, September 9, 13

63. Support
• Until recently one support engineer
(Serge Baranov) was covering all IntelliJ
Platform-based IDEs
• Best Technical Support (small to medium-sized
business, SD Magazine Reader's Choice 2005)
• Developers actively involved
Monday, September 9, 13

64. Internal Docs
Monday, September 9, 13

65. Internal Docs
• XP's belief: comments are a code smell
Monday, September 9, 13

66. Internal Docs
• XP's belief: comments are a code smell
• Most 3rd party plugins are open-source,
good examples
Monday, September 9, 13

67. Internal Docs
• XP's belief: comments are a code smell
• Most 3rd party plugins are open-source,
good examples
• Improving docs does not increase average
plugin quality
Monday, September 9, 13

68. Internal Docs
• XP's belief: comments are a code smell
• Most 3rd party plugins are open-source,
good examples
• Improving docs does not increase average
plugin quality
• Investing into docs to promote IntelliJ
Platform to companies
Monday, September 9, 13

69. Plugin API
Monday, September 9, 13

70. Plugin API
• No separate facade, plugins access
internal IDE classes directly
Monday, September 9, 13

71. Plugin API
• No separate facade, plugins access
internal IDE classes directly
• No way to repurpose IDE the way we did
without breaking API compatibility
Monday, September 9, 13

72. Community Plugins
• Large part of feature set
• Always by agreement with author
• Usually reworked at JetBrains
• Usually kept open-source
• Rewards through plugin contest
• Sometimes hiring authors
Monday, September 9, 13

73. Build System
• Not using Maven or Gradle
• Still storing dependency .jar files in VCS
• JPS: tool that builds IntelliJ IDEA project
from command line
• Same as external make in IDE
• Gant scripts to generate distribution
Monday, September 9, 13

74. Extensibility
• Not using OSGi, Guice or Spring
• PicoContainer for dependency injection
• Home-grown extension point system
• Components and extensions to load
specified in .xml files
Monday, September 9, 13

75. Non-Java Languages
• Some Groovy for tests
• Live Edit's Chrome extension written in
Kotlin and translated to JavaScript
• Scala plugin written in Scala
• Clojure plugin uses some Clojure
Monday, September 9, 13

76. Summary
Monday, September 9, 13

77. Summary
• Codebase repurposed far beyond original
goals through relentless refactoring
Monday, September 9, 13

78. Summary
• Codebase repurposed far beyond original
goals through relentless refactoring
• Full-time dogfooding is essential for
maintaining quality and usability
Monday, September 9, 13

79. Summary
• Codebase repurposed far beyond original
goals through relentless refactoring
• Full-time dogfooding is essential for
maintaining quality and usability
• Lightweight process is enough for
product development with no external
stakeholders
Monday, September 9, 13

80. Q&A
yole@jetbrains.com
@intelliyole
Develop with Pleasure!
Monday, September 9, 13