0 comments
.NET 
By now, everyone in the software development industry probably heard about "agile" development, formally described in the Agile Manifesto. Agile was a rebellious response to the continuing push of vendor-driven processes and procedures, which seemed to balloon in its efforts to describe every complex artifact and activity, preventing professionals to think up more simple solutions for the problems at hand.
The agile manifesto is a call to action to emphasize several points the big-process guys seemed less important. It's about relying less on a big tell-me-all-do-nothing-without-it process, complex tooling, huge documents without any real proof, a detailed contract and planning set in stone. Agile states that these concepts are at odds with the very nature of software development, yet were at the time (and still are at a lot of places) commonly practiced.
Whether agile is right about this (I think it is) has always been controversial and a source of heated discussions. This seems strange: if you consider "change" in a software development project as inevitable as "gravity" in the real world, you would expect no real debate on something so obvious. However, unlike falling apples, most problems and forces in software development are more abstract and subtle, and solutions often seem counter-intuitive.
Another controversy in the software development industry is about quality. To a lot of people, quality costs money, and lower quality equals cheaper production equals money saved. This very simplistic thinking leads to spending less on qualified developers, less solid testing and/or improving based on test results, less on learning, coaching and/or improving, less on usability and creative, but risky solutions.
Again, the opposite is true. High quality means better efficiency because of the extra reuse opportunities, a more predictable schedule (less meetings and re-prioritizing efforts), less re-work on testing, fixing bugs, and testing again, and higher return on investment in production, because of better features, less failures and greater user satisfaction. Actually, the best way to waste money is try to achieve the lowest quality possible, something the manufacturing industry already knows for decades.
To emphasize the value of quality and a professional attitude when developing software, the Manifesto for Software Craftsmanship has been created by the software craftsmanship group. Based on the Agile Manifesto, this manifesto declares that in order to be agile, you have to be professional. Probably, like the agile manifesto, it will lead to some heated discussions, with dogmatic enthusiasm and stubborn rejections. I think it's a just cause though: it's not just what something costs by the hour, but also what it delivers in return. If you agree that craftsmanship matters when developing software, sign the manifesto to show support!