Agile Zone is brought to you in partnership with:

Dave Rooney is a veteran Agile Coach and co-founder of Westboro Systems. He has over 20 years software development industry experience and has been involve with the Agile community since 2000, working with organisations from pre-funding startups to the Fortune 15 improve their software process. Dave is co-founder of the Agile Ottawa Group, and an active write, speaker and advocate of agile methods in Canada. Dave is a DZone MVB and is not an employee of DZone and has posted 31 posts at DZone. You can read more from them at their website. View Full User Profile

Adaptability

08.29.2013
| 3424 views |
  • submit to reddit
Recently on Twitter I was part of a conversation about how software developers become locked into their tools to the point of religious fanaticism.  Now, don't get me wrong--good tools make developers more effective, and the extent to which developers learn how to work effectively with their tools amplifies that.


What strikes me as odd, though, is that we work in an industry in which change isn't just normal, it's expected.  The rate of change continually increases, and shows no signs of abating any time soon.  This is odd because developers seem so unwilling to consider changing their tools.

My perspective on that may be skewed by the fact that I spent a good deal of my career as a contract developer.  Usually I walked into a new gig and was shown to the machine I would use, told which development environment the team used, the source control system, etc.  I simply had no say in the matter.  I had to adapt, or I could find a new contract.  I can say, unequivocally, that I never left a contract because of the tools used.

Here's a quick breakdown of the environments in which I've worked since I first started writing code:

30 Years Ago (1983)

  • Command line on an Apple ][, writing BASIC and assembly code
  • Very few editing features, but ignorance was bliss
  • A year later at university it was Sed or a similar editor on the school's mainframe writing FORTRAN

25 Years Ago

  • xedit on an IBM mainframe with REXX
  • It was a decent full-screen editor which could actually be automated to provide full-screen UIs for mainframe apps
  • I also used vi on Unix for a number of things, which felt very clunky and backward compared to xedit

20 Years Ago

  • Used the editor from Microsoft C for, not surprisingly, C, as well as a couple of other languages
  • The editor was very "comfortable" to use and I became quite familiar with it

15 Years Ago

  • Worked within the Powerbuilder, Visual C++ and Visual Basic IDEs
  • It wasn't efficient to edit outside of those tools, and indeed was somewhat risky
  • Became comfortable and proficient with all of them
  • The IDE editors were good enough to get work done
  • Also used vi when running remote shells on Unix systems

10 Years Ago

  • Various Java IDEs: PowerJ, JBuilder, Eclipse depending on the standard at the client's site
  • Executed tests within the IDE
  • Used Textpad for text editing outside of the IDE
  • Used vi when in terminal mode on a remote host

5 Years Ago

  • Used Eclipse and NetBeans for Java, Visual Studio for C#
  • Executed tests from the IDE
  • Used Textpad for other text editing
  • Used vi when in terminal mode on a remote host

Today (2013)

  • Sublime Text 2 for both text and code editing
  • Execute tests from the command line
  • vi when in terminal mode on a remote host

What's interesting about the last entry is that I feel like I've lost some of the features that I liked in the IDEs I used going back 15 years.

Sublime Text is really, really fast at indexing and searching through the text in thousands of files, but that pales in comparison with the ability to find the definition of a method in Eclipse, or to traverse a class hierarchy.  I can write macros in Sublime that will automate repetitive operations, which I liked in Textpad and sorely missed in the IDEs, but I don't have the automated refactorings that are available in Eclipse and NetBeans.  I currently work in the Ruby/Rails world, and gave RubyMine a try -- it simply choked on the size of the code base I threw at it, and just wasn't viable in this context.  So, all searches and refactoring efforts are manual.

When I observe developers working in Vim and Emacs, I feel like I'm watching a virtuoso performance by a pianist -- they make it look so effortless!  That's fantastic, and these developers do work very quickly in those tools.  What strikes me, though, is that it appears that those tools are optimized for writing code, and less so for exploring and refactoring.

The mere suggestion that developers look at using a tool different than the likes of Vim and Emacs requires a full body Nomex suit to protect one from the flames that will ensue.  However, my experience has been that it's actually not that difficult to adapt to new tools as they come along.  It does take some time, learning and unlearning but the flexibility is worth it in the end.

After all, it isn't the strongest or fastest or even the most intelligent species that survive - it's those that are the most adaptable to change.


Published at DZone with permission of Dave Rooney, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)