My Crusade for Agility: Part 2

This is the second installment of My Crusade for Agility, if you missed it check out Part One first.  As a quick recap, I went through college, not agile, I worked for a few years as a COBOL developer, not agile, then I moved to Java and despite all the new shiny tools I realized...still not agile.

So what is "agile" and why was I looking everywhere for it? Good question. At the time, I didn't know what I was looking for, I just knew that something wasn't right. Something with the way I was doing my job. I felt like I was writing good code, but it seemed to always end up becoming a lot of work to maintain. I didn't have any tests of any kind, I was spending a majority of my time in meetings, I was putting in all kinds of extra hours trying to make up all of the time I had spent in meetings, code reviews were getting put off until "later" (which never came), I was being pulled in tons of different directions working on multiple projects at the same time, and there was an overwhelming amount of work to do. Agile is what I wanted, I just didn't know it existed at the time.

I tried to implement some more agile practices, but I didn't really know what I was doing enough to sell anyone on it. After a few more years as a Java developer another opportunity presented itself with another (much smaller) company and I took it. There were a lot of reasons for me to move to a new employer, among those: my prior employer had been a very large company. One of the cons on working for a large company is that change is hard to implement, there is a lot of red tape and politics involved. I had a plenty of good things going for me, I had my co-worker's and customer's trust, I had a fair amount of influence as far as technology related decisions, but I was constantly wondering what if...

What if I didn't have to answer to corporate? What if my team was all Agile all the time? What if my team could use the right technology for the job and not have to conform to the corporate standards? What if I could deploy my own code, or change my own database, or have root access to a server? What if I could control my own professional destiny?
I asked myself these questions and I didn't really have an answer, because I'd never really experienced any of them. Part of what appealed to me about my new employer is that my interviewer had mentioned how the project I would be working on was on a small team, who had their own server, who was using an operating system different than the rest of the company, and a different programming language, and a different database, and a different application server... I couldn't believe the freedom. When I inquired into why they had decided to go a different direction for this project than the rest of the company the answer boiled down to "because we felt like it". Major selling point.

That concludes Part 2 of My Crusade for Agility. Tune again next time for Part 3 to see how my transition from a very large to a much smaller employer changed everything more than I could have ever imagined.

My Crusade for Agility: Part 1

Over the past few years I have been slowly introduced to agile development practices. Between a combination of conferences (like Iowa Code Camp, No Fluff Just Stuff, and PyCon), local user groups (like Central Iowa Java Users Group, The Iowa Ruby Brigade, The Iowa Python Users Group, and Agile Iowa), books (like The Pragmatic Programmer: From Journeyman to Master, Practices of an Agile Developer and Test Driven Development: By Example), and the extremely generous nature of agile shops in the area (Iowa Student Loan, GeoLearning, and CDS Global) (thanks Tim, Brandon and Trent) I feel like I have a decent understanding of what some good agile development practices are. Now that I have a taste for what it means to be an agile developer working on an agile team, I crave it, I need it, but I don't currently have it. This, and what I hope to be a series of follow up posts, is my crusade from the least agile imaginable developer, to whatever awkward agile puberty that I am currently in, to where I hope to one day be.


I'll start at the very beginning of my career as developer. I went to Indian Hills Community College right out of high school and got an Associates of Applied Science in the field of Computer Programming/Analysis. Indian Hills was great, I loved it there, it was hard core "code code code" the entire time. I learned a ton very quickly and got a job as a COBOL developer months before graduation. I enjoyed the challenges of real world COBOL development. I was still learning every day, I was solving problems, writing code, and working with some pretty awesome people, so I loved it. At the same time, there was a void growing inside of me that could not be filled by hacking away on top of hacks of hacks that had been hacked on since before I was born. I knew there was a better way, a more developer friendly approach to development. So I began doing side projects using PHP, Perl, Python, Ruby, Java and anything else that I could play with for free. I blamed the technology (COBOL) for the inadequacies of my environment. After a few short years as a COBOL developer I saw an opportunity to move into the Java world, professionally, and took it.


Moving from the COBOL to Java was a breath of fresh air. I had all of these nice fancy GUI tools and I was working on code that was written within the last decade. I was so smitten with working on more current technology (and source control!) that I was blind to the fact that although the technology changed, I was really just doing the same thing. Patching hacks of hacks with more hacks. There were no tests. Instead there was "spot checking" then passing the buck to BAs and QAs to do all of the "serious testing". Huge requirements documents that had been handed off from one person to the next, re-interpreted and re-translated again and again obfuscating what the business reallyneeded the software to do and why. Battling constant scope creep, missed deadlines, cancelled and delayed projects and fixing and re-fixing the same bugs over and over I began to realize that something here was broken.


Once I realized this, I also realized that I could be working on the latest and greatest technologies but if the development process was the same I might as well be writing COBOL again. I didn't want to write COBOL again, I wanted to be a part of the latest and greatest technologies, but so far my lateral move from one legacy code base to another just delayed my inevitable realization that different technology isn't what I was really seeking.
I will let that conclude Part 1 of My Crusade for Agility. I've got loads more that I want to share, so tune in next time for Part 2.