Some days ago I took part on a debate on Agilism X Traditionalism for Software Quality Assurance. Firstly I accepted to take part of it after its organizers changed the original name: "Agilism X Software Quality", as if Agilism were against Quality! Yes, there's still people that thinks that Agilism means non-organized, low-quality development, simply because agilists don't like to take a lot of notes or of using a lot of models. It reminds me of the early days of Free/Open Source, when most people that were against it never took part of a FOSS project, or even "touched" any open source software.
I read somewhere that Agilism (like Lean Thinking) means a change in the mindset. That's why, IMHO, that many people cannot understand how Agilism works. The bureaucratic mindset cannot understand how a technique that doesn't use a lot of annotations, long meetings, change management boards, hierarchical planning etc can work.
That's the same mindset found on USA's automobile industry in the 60's and 70's that was defeated by Japanese car builders. USA industry couldn't understand how a plant controlled by paper cards could work better than the enormous management structure they had, which was matured on top of decades of experience in building car - after all, they had Ford!
But the Japanese did.
And they still do, in spite of the current Toyota's quality crisis, its followers still reign in the automobilistic industry. I see people from the traditional methods in software industry with the same arguments:
-Agile doesn't scale = JIT doesn't scale.
-You need to plan in detail beforehand* = JIT has no planning tools.
-You need to take notes of everything you do otherwise you will loose control = for JIT taking notes is considered waste most of times, do things in a way you don't need to take notes.
-How can quality be controlled by developers, instead of a separate group = how can workers control quality, instead of Quality Control Department.
-etc
*(although detailed and accurate plans for software development are unfeasible in real word)
The truth is that things like automated testing, continuous integration, refactoring, and all other modern development techniques were born in the Agile cradle. These are Product related tools. Traditionalists still play with Process related tools, repeating the "if the process is good the product will be good" mantra. Yes, we need a good process, sure, however, you must try to avoid become mesmerized by the beauty of complex project management processes. Instead of putting a lot of people to take notes of a lot of stuff and correct your planning all the time, try to avoid problems, instead of trying to correct them. The focus must be on the product, therefore, product related tools will bring much value to your production chain than process related tools.
I believe that the only really scientific way of producing software is through Formal Methods (FM), because it represents the use of Mathematical principles for building software. If someone can use the term Software Engineering, are the "FM guys". The problem with FM is that they are still quite hard to understand and apply, and there are only a few people really capable of using them to produce software. While FM doesn't produce things like the tables that engineers use to simplify their calculations, FM won't reach the mainstream. FM methods are still dependent on developing "ad-hoc" mathematical models, and the ordinary developer doesn't have the skills for that - like the ordinary engineer, who doesn't develop mathematical models, instead, make use of them. Maybe when FM become usable by the ordinary developer we will be able to (really) do Software Engineering.
Therefore, we must, at least, be the closest to FM we can. Now, tell me what's more formal:
-Running code.
-Drawing models and using manual annotations to connect them to code*?
*(code generation is mostly limited to skeletons, someone will write algorithms anyway, therefore you will need to connect things by hand in the end).
You must agree with me that running code is much more formal than models and annotations, simply because the first is the thing of what software is done. So, please don't tell me that MDD is "more scientific than Agile because has the same principles of the other Engineering disciplines"... Running code means a functional machine, and that's the basic principle of... Engineering!
ps.: Like in the (hard) industry, Agilism automates repetitive tasks, such as testing and building, and this automation provides safer software verification. The other "end", Validation, is provided by BDD.
No comments:
Post a Comment