Is Design Dead?

The philosophy that is behind some of the software development practices that we commonly use in our workplaces, have grown around a vast necessity of winning the race. Sometimes, we forget that winning the race is not as important as ensuring that we will always be able to win the race in the future. This being the case, the new era of software design paradigms have born, like eXtreme Programming, which bases it's main ideas in doing things as agile and as fast as possible. Enabling projects and developers to have this level of agility, and has got some pro's and con's to consider. For starters, XP programming is based around the idea that you have to really do things, not just think about doing things. Cutting time in the design phase of the process, and giving it to the implementation and testing stages of the process can be a two-edged swords: You have a solution that's ready to use right away, but you're not a hounded percent sure that it will not represent more problems in the future for your enterprise than know.

XP programming applies in a lot of cases. I work as a Systems Administrator, and most of the challenges that I face on my day to day are really not so big in order to really have to sit down and think of classes design, test cases and so back so forth. Sometimes all I need is a simple, disposable Python program that will take me two or three hours to write. But sometimes, when the challenge we're facing is complex enough, I have to think about every use case and every single problem that giving a bad solution might represent.

It's entirely upon the bearer of the armory to choose which weapon to use depending on particular situations.