February 20, 2017 // By Jason Bock
The following article was originally published on InfoWorld.com and can be found here.
Back in 2003, I started working on a project that ended up being 15 months of amazing experiences and growth for me. This was the first project I was on that was committed to the XP process. We did pair programming. We had well-defined sprints. We pushed for excellent stories and tasks. We wrote unit tests. We had a build server.
These may all seem like aspects you would expect from a project in 2016, but 13 years ago, it was completely new. It took a couple of months for the team to get familiar with these changes, but once we started getting comfortable with the processes, our velocity really took off. The team also got along well. We enjoyed diving into difficult problems and pushing forward to solve issues.
I've always welcomed every project I've been on as both good and bad experiences are educational, but there have been a couple of projects that have been exceptional for me. This was one of them.
Given the timeline, it's not hard to surmise that the technical complexity was fairly high. However, by the summer of 2004 we were ready to pilot our application into a couple of stores for the client. This application was going to unify purchasing large orders of disparate products within the store and make the shopping experience easier and quicker for both the customer and the salesperson. We were excited, the business was excited, and then ... the bottom dropped out.
Internally, the client had decided to do a massive change with their IT department, essentially replacing all their IT employees with a consulting company that took over all aspects of IT. One immediate consequence of this change was "no new internal development." They deemed custom development as a waste and pushed to use vendor products. As a result, my project was stopped. A year's worth of effort that could've streamlined the client's purchasing pipeline was terminated for no other reason other than a generalized mandate was given at a level that none of us could challenge.
I've been on projects before that one where things didn't go well. That's the reality of software development. If there's one axiom that I know is true while working on a project, it's this: expect and adapt to change. Nothing is set in stone. Requirements change. User needs change. Technology choices change. It's to be expected, and we have to be willing to work effectively with an evolving environment. But this change was really hard to take. I had never been on a project that had so much work put into it, only to be put on the shelf permanently. It was demoralizing and emotionally draining.
I'm guessing that a fair amount of you have been in positions where projects have been cancelled, or your company has taken a financial turn for the worse and you've been laid off. Such actions can be bewildering, leaving one with continuous thoughts of future financial stability and potential career changes. In my case, I was still employed by my consulting company, but being a consultant means you stay billable as much as possible. Therefore, "hitting the bench" is not a desirable thing. Fortunately for me, I was able to get on a different project fairly quickly, and I moved on. But how does one move on when they've invested so much into something, only to see it stopped?
I've been reading a book by Gene Kranz called "Failure is Not an Option." In the chapter "What Do You Do After The Moon?" he talks about the end of the Apollo missions and how it affected younger members of Mission Control, who didn't understand why the program wasn't going to continue and what that meant for their careers. He talked to these employees about their future:
In 1971 a big part of my job was convincing my young controllers that there was a damned interesting and challenging world after Apollo…I am a dreamer, believing that the mark of a champion is the ability to thrive in tough times…We can make the future ours if we believe and fight to make it happen.
That may sound a little sappy to some, but I believe a positive vision like this is necessary in life. We don't always control the technical pathways and decisions made on a project, and sometimes choices are made that can adversely affect our careers. There may not be an easy way out, and having support from friends and colleagues helps tremendously, but ultimately the path to success in one's life is measured by their adaptability to adversity. Learning new programming languages and frameworks, adjusting to a new culture at a new company -- these can be opportunities for growth in your career. Until next time, happy coding!