In the late 1990’s, I was working on a paper in a computer ethics class on one of the hot topics of the day which was the implementation of Carnivore (later Digital Collection System 1000 or simply, DCS1000) by the FBI. Basically, these were strategically placed packet sniffers used for the collection of email and other data. The FBI would gain permission to place this system at an Internet Service Providers location and start intercepting data. As a young and naive computer scientist, I was up in arms that my personal security was being compromised by my own government. In this pre-9/11 era, the FBI was attempting to explain such shenanigans as protection against the organized crime syndicates of New York. Certainly a hard sell to say the least.
Unless you are transporting goods from Morocco to Egypt on a camel train in the northern Sahara, you are aware that a new system for domestic spying has come to light with a much broader functionality than Carnivore. Fortunately, the NSA has seemed to pick a better name than the FBI years before. Prism brings to mind a friendly Dark Side of the Moon album cover and succeeds in giving me a warm fuzzy feeling, where carnivore brought to mind T-rex with his stubby arms flailing in the Jurassic era wind getting ready to devour me. However, even with the NSA’s benign name, it is hard to overlook the magnitude that has revealed itself over the past couple of weeks. Initially, I was shocked. Surprised as I was more than a decade ago when I saw my privacy dissolving before me. However, keeping in mind that privacy will generally degrade/improve cyclicly based on available technologies I would certainly think that this is a ripe time for the clever software engineer. (more…)
Mention Rails, and you will often believe you are debating White Castle burgers. You either love or hate it with little room for anything in between. DHH created a framework where you generally have to play by his rules and if you disagree with those rules, you might become frustrated or a bit disgruntled while working in the framework.
Whether you are comfortable working within DHH’s framework or not, the fact is that the train is moving and it includes new features that will improve your apps as the version matures. Developers using Rails will cringe at points similar to what we felt with the introduction of the asset pipeline. Even tonight, as I write this post, I have had a moment of asset pipeline cringing. Hating the change… or as DHH puts it, the “progress”…
However, there are numerous advantages to using Rails and the newest installment will build on and create new features that will make development easier, more secure, and more fun (at least we hope in the long run).
Almost 15 years ago, while still working on my undergraduate degree, I took a series programming classes as part of my CS curriculum. The first day of class, the professor announced that we would not be following the standard programming practices of the time, but would be following an experimental methodology. It would include, paired programming, daily standup meetings, unit testing, iterative releases, and the slew of other methods that was known as XP.
As with most new methods, the Departments decision was met with controversy. Even among the students, the new techniques seemed foreign and unusual and were met with hesitation. For example, how do you fairly grade paired programming assignments? While most of these issues have been addressed over the years, the increase of a remote workforce has created new issues. Fortunately, the issues are being addressed and the solutions are increasing production and creating a more enjoyable work environment. I believe this trend will continue. Better software will be created and communication techniques will improve. It seems likely to me that this trend is unstoppable at this point. As developers, we’ve created fantastic tools that fit nicely in to the distributed work methodology. Tools that may not have been intended for this purpose, but definitely work in synergy with current project management methodologies. These tools have seemed to almost naturally evolved in to collaborative tools that are being used successfully daily by remote workers.
Communication, Continuous Delivery, Changing Requirements and Frequent Releases
Obviously, development can be quite complex, but broadly, it boils down to communication and the actual development process. If these are successfully addressed, the project stands a high likelihood of success.
Communication is a key factor in most activities in life and this certainly holds true for the development process. Without the foundation of communication, everything else crumbles. Fortunately, it has become easier to communicate with someone on the other side of the country than on the other side of the cubicle. In my past cubicle experiences, I would typically Skype my cubicle neighbor because it was actually faster and more efficient than going to talk to them. Whether you are using Skype, Google Hangouts, GoToMeeting, Speek.com, or Join.Me, these tools for communication and collaboration are helping to dissolve the distance between our peers. We have the ability to have face to face communication with almost anyone, anywhere. Whether you are in the middle of a paired programming session, working with a Client on project requirements, or just discussing development with your colleagues, the abilty to quickly and efficiently communicate exists.
Virtually all of us are using some sort of cloud based source control, such as Github. And increasingly we are using various Platform as a Service solutions or creating our own deployment solutions. The ability to push and share your code now is similar in most organizations. It’s a process that should be (and generally is) quick and easy. For years now, we’ve been able to share code through various source control methods and it is almost always something that can be done in a distributed environment.
What’s the issue?
When I worked with Cisco shortly after college, they allowed their employees an incredible amount of flexibility. I was even shocked at the time. However, as I got to know and work with their developers, I began to see that it did indeed work out well, even using technologies that are now more than 10 years old. The sales teams were able to complete their jobs and the developers were happy and productive. Even newer companies like Github provide a tremendous amount of flexibility to their employees realizing that developer inspiration does not happen necessarily from 8-6, Monday – Friday, or in the office. Great software is being developed by teams of distributed and remote workers and it is truly amazing to look at how far we’ve come over the past couple of decades. We have the ability to live where we want with increased flexibility and increased productivity. It seems unfathomable that some organizations, such as Yahoo! have recently rejected this progress. I certainly do not understand this decision, but it probably really doesn’t matter in the long run, we have now passed the Rubicon. We are creating at light speed and I can’t imagine where we will be in the next 20 years, but I am optimistic that it will be pretty cool and I’m confident we’ll get there on the shoulders of remote workers.