Rapid Application Development Doesn’t Mean Fast Typing

Although developers love to type fast and don’t want the mechanics of putting a solution in place slow them down, the emphasis in the development community has been grossly misguided in the recent years. Let’s look at a bit of history of what’s happened over the last couple of decades. Some attribute this to the exodus of most competent developers leaving behind “enterprise” development that was saturated with red tape, vendor-lock-in and Not Invented Here rhetoric. So where did they go and what did they use instead? A lot of them went out and got a Mac laptop mostly as a sign of dissent from Microsoft as the platform responsible for past hardship. This meant going back to basics and using Vim or Emacs as the code editor of choice. Even good tools like Intellij IDEA and Resharper were tied to a bad taste of Java and .NET and were ditched in favour of the command line rediscovered. You could see these hipsters in cafes all around the world, liberated from former medieval shackles and eager to get some start up going! While for the most part, ditching that past is very good, some other things that were discovered and helped rescue the industry from a worse fate were thrown out too.

One of the things that got us going into a new age of software development was eXtreme Programming (often referred to as XP) and often just rolled into the loaded term “Agile”. While the idea encompasses a number of practices, the ones relevant to this topic are Test Driven Development and Top Down Development. Test Driven Development is also referred to as Test-First development often as it reflects the idea that no code is to be written unless it is fixing a broken test. This allows the programmer to keep a clear goal for the next bit of programming. This way of working requires a lot of disciplined practice to evolve the design – which may not be the best outcome sometimes but I’ll leave that topic for another post. It also introduces the concept ofRefactoring so that as you add more and more code, you take a break and clean up redundancies and other sub optimal resultant code. Vim, Emacs, Sublime, Brackets, Atom and other thin editors can’t do that. They try, but they can’t.

Your Minimalistic Hipster Tooling Ain’t All That

So why is Vim or Emacs not enough? Surely you can attain the above with Vim or Emacs, right? Well yes and no. And the no is the interesting part. You can’t take advantage of across-the board code navigation, refactoring and other solution-wide changes that will keep logic flow integrity. The part that makes all that possible is the concept of an Abstract Syntax Tree that keeps track of what the code in text format actually represents. So if you rename a method, you can be sure that wherever that method was used, that text is also adjust – but the occurrence of the word in strings or in a different namespace are left alone. In a regular text editor, there is a lot of clean up that needs to happen after a search-replace when attempting a similar refactoring. This is where you will see the fast typing or illusion of productivity instead of actual rapid application development.

Top-down development is another pillar of responsible development. You start by writing out a test as if the class and methods already exist. The test will not run and not even compile as those pieces don’t exist yet. However, with a proper IDE, you can quickly combine a few keyboard shortcuts to generate the uninteresting scaffolding and get to the interesting business logic needed to make that test pass. As a side note, this is one definition of what an IDE should provide – not just a text editor with a bunch of panels attached for managing related resources like source code management, database administration or other non-code benefits). Here is an example in Resharper using the IntelliJ key bindings:

Alt+Enter, Enter choose the first choice to implement the class that doesn’t exist yet
Shift+F6 move the class out of the test project and into the solution project
Control-minus jump back to the previous edit place which will be your test
Alt+Enter, Enter on a missing method that’s being tested will generate that method with a “throw unimplemented exception” implementation
Control-minus to jump back to the test.

Now your solution can compile and the test can run but still fail. You can jump to your TODO list with another shortcut, implement the logic, run the tests see them pass, alt-tab to your console commit and push your changes. The number of keystrokes needed in Vim or Emacs is an order of magnitude greater.

UPDATE: You can get most of this with OmniSharp for C# and the GoLang plugin for IntelliJ is very close. This article has brought to light where some of the tooling has progressed to.

Who’s Going to Strip the Developers’ New Clothes?

I’ve already hinted at who’s going to provide the return to normal: Jetbrains. One of the biggest rifts in the development community happened in the Microsoft space. Visual Studio has been the host for Resharper and gave the ultimatum to many developers that were sick of what was coming down from the ivory tower: Put up with a bloated Visual Studio (the latest version takes, at minimum, 7GB of harddrive space) and large, proprietary, sub-optimal OS called Windows to keep the joy of Resharper refactoring, or abandon all of that for small text editors in *nix with no refactoring on a half-baked .NET implementation called mono. Some took the latter choice and some chose not to play at all and started learning Java, JavaScript, Ruby, etc.

The point that I would like to emphasize is that in switching platforms and language, the rapid application development aspect of top-down development and refactoring tooling was lost in the mess. Some, like me, would not give up on the fast refactoring and discovered other places to develop like Android development that got an intelliJ fork called AndroidStudio. And there were others: PhpStorm, PyCharm, RubyMine, WebStorm and many others now. All supported the similar keybindings and could be configured to have identical ones.

But it gets better, hell froze over and JetBrains announced ProjectRider a couple of weeks ago. A cross-platform C# IDE in line with the rest of their IDEs that brings all the features that Resharper gave. Even though there is no support for new .NET versions or C# 6, you get to develop on Linux erasing the need for the huge resource drain and vendor lock in that Visual Studio and Windows imposed. That means that a lot of the C# code base that exists in the world can be maintained for a fraction of the price with the blistering speed of intelligent code navigation, top-down development and refactoring. This helps Mircosoft a whole lot. It makes those that left their ecosystem for many reasons have a second look and go back to develop in .NET and C#. Unfortunately, we still have NIH from even the most forward thinking Microsoft insiders and they choose to ignore this major development on purpose (ref. lack of twitter activity from them about it while discussing a new scheme for naming versions in their existing stack).

UPDATE: Unless ProjectRider can go live on Linux soon, OmniSharp will make it redundant to do so. The competition is definitely benefiting the development community.

Keep Your Eye on the Prize

While this last development is a major step in the right direction, we are far from where I thought we would be by now. What if we didn’t need a GUI environment for an IDE (see my definition of IDE above)? I don’t need a windowing environment to code. I want ProjectRider, WebStorm and the others available on the terminal – we’re just dealing with text. NCurses and other textual visualizations can enable the helpful popups that we see when we hit alt-enter in IntelliJ, on the terminal. I can configure tmux to launch something like watch git status and run tests in different panes to get what are the unimportant parts of the IDE. There is so much to look forward to. Let’s not lose sight of what it means to code, demand this from the communities/organizations and keep it light, fun and inexpensive!

UPDATE: With OmniSharp allowing any editor front end for C#, developers will hopefully see the same for other languages from similar efforts more and more. An open-source AST would help.

Comments are closed, but trackbacks and pingbacks are open.