OSS and Devops and the Impact of Tool Proliferation

I’ve ignored this blog for the whole semester. It just wasn’t happening. Both my students and I made it through Fall 2015. I’m exhausted but happy with the experience.

Tool Proliferation

I’ve had a few frustrations, though:

  • The Java dev environment has exploded with tools, frameworks, and… well, lots of stuff we never needed before
  • In the current version of Android Studio, the only way to get JUnit tests to run is through Gradle
  • Gradle needs to be updated out of the box, and school’s internet is slooooooow
  • The manuals and how-tos for Android Studio were for an older version, and the AS team moved things around (I think sensibly, but nonetheless I had to hunt around)
  • I could never get JUnit 4 to work, but JUnit 3 did fine

While I fully understand the need for libraries, the proliferation of tools has made a fairly simple environment needlessly complex. As with all programming tools, these can be described as “a nice place to live, but I wouldn’t want to visit there”. However, unlike the UNIX command-line and editors like vim and emacs, massive changes are the norm.

The Issue With Devops

The explosion of devops has actually made this process worse in some ways. Don’t get me wrong, I love devops; it’s not enjoyable work for me, so having someone else take responsibility is a wonderful idea. Wonderful, that is, if you have someone who can do the work. A big organization can have dedicated support for tools, integration, and deployment, but those people need their own tools. Because I don’t have time to dedicate to the maintenance of a production environment, I’m left wondering what needs to happen and which tools serve what goal.

Since I don’t have the luxury of someone devoted to devops, I pay the price. I spent an extra 20+ hours helping my students properly configure Android Studio to use JUnit. Their efforts were insufficient, because they didn’t know the underlying environment.

I no longer write massive amounts of code in Java, but I do teach Java. It’s difficult to “teach around” the complex set of systems that are integrated into current dev environments. Sadly, many of these tools have horrible user interfaces, even for programmers, and they are often poorly documented. What they actually contribute can be vague because they’re open-ended.

Open Source Software, Too

Part of the problem is the open-source movement. Yep, I said it, OSS has downsides. Anyone who wants to can build a Linux distro, or a window manager, or a build tool, or a version control system. The last is particularly frustrating, since the new “standard” seems to be git. What was wrong with subversion? Why are we all using git? Yeah, I know, Linus and the kernel, but git was built for the kernel and the processes built around contributing to the kernel. From an organizational standpoint, there are few projects like the kernel, which has developed its processes over the last 2o+ years.

The Problem Itself

Why is this a problem? New programmers.

I’ve been encouraged many times to integrate dev tools into my courses, especially the intro courses. To the extent possible, I do this: github generously gave me some private accounts through their educator program, and my students will be using them.

Most of the time, though, has to be dedicated to teaching fundamentals. These are students who hadn’t seen code in August, so they’re not yet productive, let alone nearing mastery. Every day I teach a dev tool is a lost day for programming. Every day I spend learning a new tool is a day I could have spent on other subjects.

When onboarding new programmers, even trained ones, there’s inevitably spinup time. However, these additional tools are extending that spinup time greatly.

In Conclusion

I’m going retro next semester. To start with, students will not use an IDE. I’ll let them have Notepad++, but they will compile and run at the command line.

There is a solution here: fasttracking. The tools don’t need to change or go away, but they should have standard configurations that are easy to set and don’t drop the user into the deep end. In addition, all of this should be configurable by text files. Why? Because they work. We use them all of the time in UNIX/Linux environments, and for good reason. If you want those files to be XML, fine, but make sure that they have a minimal configuration level. If you want examples, look at apache. No, it’s not a pretty system, but if there’s a need to move around user interface features, the text files mean that I can control what’s going on and can solve issues. Explaining how to fix an error caused by misconfigured apache config files is really pretty easy; 95% is commenting or uncommenting a small number of lines, and perhaps 5% require additional lines.

End rant.