Over the past few years I have been gradually introduced to agile software 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 COBOL to Java was a breath of fresh air. I had all of these 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 really needed the software to do and why. Battling constant scope creep, missed deadlines, excessive processes and paperwork, canceled 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.