Hi all,<br> <br>All posts here are well meaning... but there are a few premises which in my opinion are faulty and bear deeper examination.<br><br>One premise I find most faulty is "Drupal is entering the corporate world, it must shape up to standards".
<br><br>At the heart of this apparently commensensical affirmation is an (unwitting?) hiding of the fact that it is the corporate world that is turning to open source communities as a way of improving quality that marks the epoch, and not the inverse. And there are reasons for this.
<br><br>Drupal's intelligence as being practically a virtual machine while remaining procedural, its clean super modular approach, etc., is a result of what already works: the bazaar: we must avoid the temptation of the cathedral.
<br><br>That is, the excellence, the quality, is the result of a huge mass of people aiming the bullets of their rifles at the same place, plus the natural acceptance of meritocracy.<br><br>In other words, the quality of Drupal arises out of the dynamics of a natural open source community. Attempt to overmanage that, attempt to meddle with what is already working, is to allow the same people who brought you corporate buyouts, the US mortgage-banking crisis and the Katrina aftermath to bring their excellent organization skills to the table.
<br><br>The corporate world has been with Drupal for quite some time now, and is enjoying it as it is. Those 7 million dollars for Acquia didn't come out of thin air. Offices opening in China neither. And the purchase of smaller shops by larger shops could be a healthy thing and then again... where have we seen that pattern before?
<br><br>Another premise I find faulty here is that of the emphasis upon individual certification. In the real IT world, quality sites come out of collectives, cooperatives, studios, companies, groups working together, and following some kind of capability maturity model. And corporations realizing that their vertical systems of organization clash with quality, among other things, so that the best projects come from outsourcing and insourcing. Without wanting to change the nature of the thread, I would say that quality arises out of some kind of marriage between the capability maturity model (a concrete plan for quality improvement over the years in a stable organization) married to some kind of agile approach to development. And the capability maturity model includes excellence in dealing with suppliers. Excellence in treating us, the Drupal consultants, so as to get the best results.
<br><br>The third kind of premise I find faulty here is the "every time I hire someone they fail" variety. That's like blaming the bus drivers for the traffic jams. Here's the contradiction. Drupal is an extremely productive framework. That leads many unscrupulous businesses to dream up get rich quick schemes and to think that Drupal is a magic cloak for easy exploitation of "Web
2.0". So, just like every other corporate boss, they want to hire someone quick, squeeze the brainy juice out of them and start counting their money. Or in the case of some non-profits, they expect instant solutions while offering little in the way of technical stakeholders.
<br><br>So I would submit for consideration the counterpart: the instability of many corporations and NGO's lead to excessive demands, the need for everything to be ready "yesterday", the need to extract a pound of flesh from the hirelings. More than certification, we need a bloody union.
<br><br>So, let's beware of corporate crises and hysterical forms of organization overturning the carts in the bazaar, let's beware of crass individualism and the hiding of the group effort and the fact that one is standing on the shoulders of giants, and let's beware of corporate greed as a tool of organization, and let's beware of the need to extract surplus value from Drupal developers as a building block of quality and excellence.
<br><br>And let's beware of tinkering with something that is already working. And let's beware of what is demonstrably not working in the world as a whole.<br><br>More than certification we need a bloody union!!!<br>
<br>Victor Kane<br><a href="http://awebfactory.com.ar">http://awebfactory.com.ar</a><br><br><div class="gmail_quote">On Dec 21, 2007 7:27 AM, Liam McDermott <<a href="mailto:liam@intermedia-online.com">liam@intermedia-online.com
</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Chris Johnson wrote:<br>> Understanding how most of Drupal works and being able to use that
<br>> knowledge are probably among the key things that a Drupal developer<br>> would need to know. Can the former be mapped onto the latter in<br>> some sort of systematic way? Hmm.<br></div>Thinking about the way other practical tests work, the driving test in
<br>the UK comes to mind (probably the same across the world). Examinees are<br>given a set of tasks and if they complete them without triggering any<br>failure conditions--such as breaking the speed limit, not indicating
<br>when turning etc.--then they pass. Drupal could have something like the<br>following failure points:<br><br> * module doesn't work or doesn't implement specified functionality;<br> * module has been copied from the Internet (cheating);
<br> * did not adhere to coding style;<br> * used database system specific PHP function call, e.g. mysql_query();<br> * generated UI elements without theme functions or forms API;<br> * uploaded/manipulated files without using the file interface;
<br><br>In the driving test examinees are allowed to make a certain number of<br>minor mistakes too, example Drupal minor mistakes: minor errors in<br>coding style (like forgetting a newline before an else {), not writing
<br>portable SQL, or allowing data processing into their theme functions. So<br>examinees must write a module without triggering any of the failure<br>conditions (and without making too many minor mistakes). Then the<br>examiner just uses the check list of problems to look for.
<br><br>The modules coded in tests could roughly implement the topics on this<br>page (or the important ones like FAPI, database abstraction etc.):<br><a href="http://api.drupal.org/api/groups" target="_blank">http://api.drupal.org/api/groups
</a> this could make a good start.<br><br>Kind Regards,<br><font color="#888888">Liam McDermott.<br></font><div><div></div><div class="Wj3C7c">_______________________________________________<br>consulting mailing list<br>
<a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br><a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br></div></div></blockquote>
</div><br>