Coding Without a Net - The Week of No IDE, Days 3 - 5

This is the third in a series regarding my experiences in dropping the use of an IDE for my day-to-day programming tasks.  For some background, you may want to check out my initial post where I lay out my plans and the post covering Days 1 & 2.

The third consecutive day of the Week of No IDE found us fully tooled up and with an understanding of how we would interact with our code and the project.

One major challenge we had encountered in Days 1 & 2 involved the adding of new source code files to our project.  Reviewing this problem took up more than a little time.

When you write code in Visual Studio, each individual source code file must be referenced by the common project file in order to become part of the build.  The project file itself may actually, in turn, be part of a larger "solution" file containing references to multiple projects which can be part of a sort of mega-build.  These references to files are not just the location of the files, but also information on what role they play in the project.  For example, a Typescript file will be referenced differently from an HTML or C# code file.  While this may seem great for organization and make it easy for Visual Studio to create pretty displays, Microsoft decided that there was no need to make it easy to add these references without using Visual Studio itself.

The end result was that Todd and I found ourselves struggling to efficiently add a new Typescript file to our project.  The process looked something like this:

1. Create the Typescript file in the location where we want it to reside
2. Open the main project file, which is thankfully in XML format, in Vim
3. Locate an existing Typescript file reference in the mass of XML
4. Duplicate it, placing the copy below the original
5. Change the path in the copy so that it references our new file
6. Save the project
7. Build the project and ensure that our new file is included in the build

The same process worked for C# and HTML files, as well as others.  Although the process worked, it was not pretty or efficient.  I considered writing a quick utility that would do the dirty work for us, but we'd already lost time and I was more than a little annoyed that no one had already done this.  A Google search turned up nothing apart from StudioShell, which does not work outside of Visual Studio (no matter what its docs may say to the contrary), and a promising post on StackOverflow. All fell short of my goal, so I just stuck with editing the XML.   I may yet revisit this and do it myself.

(Don't get me wrong about StudioShell, however.  We already use it and it's a really great tool once you learn it.  You can do some very powerful stuff with it in Visual Studio.)

File-management challenges aside, Day 3 turned out to be relatively productive for Todd but less so for me due to administrative duties kicking in.  The good news is, we managed to move several items on the Kanban board during our first few days.

Both Todd and I took a week long break for Christmas in the midst of this experiment, so Day 3 was actually the end of our first "week."   Upon our return, we did not go back into pair programming mode.  Although our team members often pair up, we don't practice continual pair programming, so our final 2 days were executed solo.

During this time, I continued to work through difficulties with using my editor and the APIs, but I did manage to get into flow a few times, so much so that I neglected to tweet what I was up to.  Once I got past the desire for the editor to catch all my mistakes and instead let the build process point me to the problems, I found I was doing ok.

An interesting side effect of "build-based debugging" is that your time-to-build becomes critical.  I actually tracked down a few issues that had been causing our project builds to run longer than they needed to and shaved a few seconds off each build, which was huge for my new workflow.

Using the build as your syntax check also forces you to focus.  Visual Studio, like most IDEs, will analyze your entire project and show you a list of errors.  This is usually considered a good thing, but it can make you lazy, allowing you to jump around from file to file making wanton edits, without concern about their effect on other files in the project because the IDE's error list will warn you when you run off the rails.

In my case, only when you build do you get the news and the news is often not pretty.  So I found myself building far more often to ensure I hadn't gone too far astray.  This greatly focused my attention on where I was working at the time, and I do think it helped not only my concentration, but also my awareness of the effects of my changes.  I became a little more conservative in my changes to public method signatures, for example, and was more inclined to make my methods private, allowing external needs to force them into the public space.  This is, of course, good coding practice anyway, but I did feel new, positive influences on my behavior as a result of my workflow.

Overall, I think it was an interesting exercise which gave us some insights into our knowledge of our toolset, exposed us to some old but still excellent utilities, and which exposed the incredible lengths to which IDEs have become embedded in the workflow of software development.  I don't think our brief experience truly answered the question of whether IDE-reliance is good, bad, or just plain ugly, but it was a fun diversion and I think I did come away with a little more situational awareness of my coding activities.