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
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
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
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
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
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
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
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
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
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
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
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
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
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
