Since I stopped blogging regularly I’ve become somewhat involved in a community of programmers called Alt.NET (Alt Dot Net). Without going into a long diatribe about what Alt.NET is specifically, it’s main goal is to find a better way to program via processes, ideologies, and overall betterment of the software development craft as it relates to Microsoft’s Dot Net platform.
Chad Myers has written up a nice article on Professionalism that I think everyone should read if only for the call to continue to better ourselves and our processes as software developers. This article has sparked much of what follows. If you don’t understand what some of these phrases, and ideologies are exactly, I recommend Wikipedia to help you get at least an overview of them.
There seems to be a mission to find the holy grail of software development processes and ideologies. There’s Agile, Lean, RUP, Waterfall, Object Oriented Programming, and about a hundred other methods, ideologies, design, and architectural methods and ideals. Some will tell you that Agile the best process while others will argue for a more waterfall like approach to the process. Others will swear up and down that Lean is the only way to go. The problem with these kinds of arguments is that as we work to find new and better ways to do things, we have a tendency to force them to work in the environment we’re in. We do this rather than try to find the solution that works best for the environment we’re in.
Sure some of these process methodologies can be adapted easily and inserted into the environment we’re in and the ones that can should be looked to first because they can be easily changed to work in the environment we’re in. However it has been my experience that some people will toss out an idea, practice, or process just because it isn’t “alternative” enough for their liking. I think people that think like this are doing a disservice to their team, their potential client, and even themselves.
The idea to find a better way is a noble mission. It is one that will challenge a person and group constantly. But to toss out ideas, processes, or a practice simply because it’s “old school” is like saying why use a wench with a socket wrench is so much more efficient. This might be true in some instances but sometimes that plain old wrench can get into places that socket wrench can’t.
Instead of looking at each new process, practice, methodology, or ideology in the realm of software development as a better way to do things overall, why not instead look at it as another tool in your tool box? Why look for a holy grail that doesn’t really exist? Not every process is going to work for every situation. For those times, why not look at the other tools in the toolbox?
Like this:
Like Loading...
Related
Michael Koby 
Dev Process is Another Tool
Since I stopped blogging regularly I’ve become somewhat involved in a community of programmers called Alt.NET (Alt Dot Net). Without going into a long diatribe about what Alt.NET is specifically, it’s main goal is to find a better way to program via processes, ideologies, and overall betterment of the software development craft as it relates to Microsoft’s Dot Net platform.
Chad Myers has written up a nice article on Professionalism that I think everyone should read if only for the call to continue to better ourselves and our processes as software developers. This article has sparked much of what follows. If you don’t understand what some of these phrases, and ideologies are exactly, I recommend Wikipedia to help you get at least an overview of them.
There seems to be a mission to find the holy grail of software development processes and ideologies. There’s Agile, Lean, RUP, Waterfall, Object Oriented Programming, and about a hundred other methods, ideologies, design, and architectural methods and ideals. Some will tell you that Agile the best process while others will argue for a more waterfall like approach to the process. Others will swear up and down that Lean is the only way to go. The problem with these kinds of arguments is that as we work to find new and better ways to do things, we have a tendency to force them to work in the environment we’re in. We do this rather than try to find the solution that works best for the environment we’re in.
Sure some of these process methodologies can be adapted easily and inserted into the environment we’re in and the ones that can should be looked to first because they can be easily changed to work in the environment we’re in. However it has been my experience that some people will toss out an idea, practice, or process just because it isn’t “alternative” enough for their liking. I think people that think like this are doing a disservice to their team, their potential client, and even themselves.
The idea to find a better way is a noble mission. It is one that will challenge a person and group constantly. But to toss out ideas, processes, or a practice simply because it’s “old school” is like saying why use a wench with a socket wrench is so much more efficient. This might be true in some instances but sometimes that plain old wrench can get into places that socket wrench can’t.
Instead of looking at each new process, practice, methodology, or ideology in the realm of software development as a better way to do things overall, why not instead look at it as another tool in your tool box? Why look for a holy grail that doesn’t really exist? Not every process is going to work for every situation. For those times, why not look at the other tools in the toolbox?
Share this:
Like this:
Related