This blog is going to by my opinions and thoughts on general software development, especially with regard to <i>agile</i> development practices. I am not an expert in these things but I do have ideas that I like to share and hope that by doing so they may generate some discussion. I will also be doing some research regarding software tools that can enable and enhance different areas of agile development in the real world.
One issue with agile development is that it often seems so impractical. Much of the time people will say, “Yeah, sure that works fine in academia but not so great in real software development.” I find myself saying this from time to time but have found that in reality, when I really, honestly adopt agile practices it may take some getting used to but they really do pay off fairly well and <b>do</b> work in practice.
A lot of misconceptions float around though. Having lived through, and currently living through, transitions to agile methodologies I’ve noticed that actually getting a team to adopt agile practices is really, really hard. There’s too much confusion about what things even mean, what tools to use, how to do things without taking forever, etc… Most places only sort of half adopt some agile processes.
A great deal of the early parts of this blog will be written in sort of tutorial fashion. They may even sound argumentative. Part of this is going to be due to why I decided to start this blog: to provide instructional material for people who will never see it and to whom I’m actually not even allowed to distribute. I’m in a frustrating position in other words and this is going to be an outlet for that frustration.
I’m also going to be teaching myself quite a bit as well. Being frustrated as I am the goal is to see if I can develop a real system for applying agile practices, especially with regard to C++ development but also with disparate systems implemented with multiple languages. Should I get to the point where I can I hope to eventually break out of my current situation, move off on my own, and maybe I’ll be happier that way. One of the biggest problems I’ve seen in the whole agile world is that there’s lots of advice about what you should be doing…but not a whole hell of a lot on how to do it. I want to solve that problem and hopefully develop a recipe that can be followed for most situations and companies.