Main image of article Developers: Are You RAD, Agile or Chaotic?
Perhaps you are a Waterfall, a Spiral, or an Incremental. Like other vocations, technology is heavy with acronyms, titles, methodologies and models. Sadly, except for being required to always have a flowchart with me while working in the lab years ago as a CS student, I don't recall discussing, much less utilizing, various software development methodologies and their strengths or weaknesses. Several days ago I was chatting with an IT guy and inquired about his title of Application Developer. I asked what he developed the apps to do, and if if he developed them for the enterprise. He said he develops relational database apps, but not for the enterprise. In order to meet the needs of his customers he's a RAD: a Rapid Application Developer. His customers, small business units within the enterprise, have specific requirements that would clash with a lengthy software development methodology. I've been a RAD,and a non-RAD. In one of my positions I worked on projects that took months. My job description, which was several paragraphs long, specified that de-railing my train of thought with unrelated matters could cause a delay of up to an hour for me to get myself back on tracks Funny thing is that I didn't know I was a RAD, sometimes producing a working app in a few days. All I knew is that it was a completely different experience from my non-RAD days. I frequently utilized what I believe is an Incremental method -- I developed a program that did something, then added the expected functionality in increments. Quite frequently I continued to receive requests for additional utility and would modify the code. But that was my job, to provide software that met the needs of my customers, either internal (co-workers) or external (clients). I wonder how many folks working in IT are aware of the specific methodology they use. Or are you simply trying to get your job done, and understanding these models are more of an intellectual, and perhaps academic, exercise that makes an interesting read (or not). How many of these methodologies are actually used exclusively, or how many software projects are a not-very-clear mix of various methodologies based on needs, time and intended use? What do you think? Post your comments below.