Earlier this summer, I spent a few days onsite with a client working through hammering out requirements for an upcoming large project. One day during a lunch break, my client asked me a question that I’m surprised no one has ever asked me before:
“We want to be the best client you’ve ever had. What do you wish we knew so that can happen?”
I think that I came up with a fairly reasonable reply at the time, but I’ve been ruminating on the question all summer long. Here are the first five things on my list of what I wish all my clients understood about developing software: (more…)
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.
Discussing your project with one of our developers is a great way to begin the process.