Zen and the art of website procurement: why bureaucrats should get their hands dirty with technology

In the past few years I worked for several public sector agencies. Much of my work consists of thinking up and delivering projects that happen mostly through Internet channels. This is a good time to take a step back and muse on what I learned. As always, the most valuable lessons come from mistakes made – so it’s a good thing I made a lot of them.

  • Software-as-service is a bad idea, though there are exceptions. My team and I made this mistake with Kublai, as we decided to deploy our platform on Ning. That allowed us to be up and running in half an hour, no small advantage; but we paid for it by sequestering our own database, procured and paid for by the Italian government, and handing it over to an American private company forever. A year later, Ning changed its CEO and business model: it moved its platform from the open source to the full copyright domain, disabled APIs and blocked migration tools. Just to do a network analysis, Ruggero Rossi had to write a web crawler – a bit like picking the lock to the door of our own home. It could have been worse: we were using a free service (that was before Ning rolled out pricing plans). If the company had simply shut down business, formatted the hard drives and walked away we could not have stopped them, since we were not in any contractual agreement. They would not even answer our emails. I am never going to even consider again rolling out a public sector project in which my agency does not have root access to the server hosting the database.

  • Using proprietary software is not a good idea either, again with some exceptions. It is expensive and it amounts to a open-ended commitment to your supplier. If a large software house develops custom software for you and then sells you the license, no one, except that same supplier, is ever going to be able to tweak that code. You risk finding yourself disempowered and stuck in a situation in which changing the color of the background or the font is expensive (as in billable hours expensive) and involves a lot of administrative friction. Furthermore, it is politically questionable: proprietary software is not reusable for free by other administrations, and that is not good – especially in a time of budget cuts and of (justified) skepticism vis-a-vis the effectiveness of administrations in spending taxpayer money.

  • That leaves free/open source software. I have been using WordPress in public sector projects since 2007; for the Edgeryders platform, more or less finished as of this week, my team ventured into Drupal. Working with open source software can be hard and frustrating. Features that are supposed to work simply installing a module or a plug-in turn out to have horrible bugs in practice; everything takes longer that you think; most of the work is not developing, but debugging. Meanwhile, the rest of the projects activities are stalled. It feels horrible. I think experience can mitigate the problem, but never really solve it. Free software is by definition organic and gritty: it works by hacks and duct tape as well as by elegant, rational solutions.

Despite all the problems, my experience of Drupal procurement is going to be positive in the end, as with WordPress before. The reason is this: these platforms allow, and even require, a hybrid figure of “power admin” to emerge, somebody who is less skilled than a developer but more so than a normal user. This happens because the admin interfaces of WordPress and Drupal are intuitive and very powerful; Drupal, especially, allows fine-grained control over your website. You can query the database, format the return of the query and send it to a page, a block or even an email message; you can tell the website to execute instructions of the kind IF [condition] THEN [action], not quite programming but on the border. Furthermore – and here I am thinking about my standing love affair with WordPress – when the admin interface is not enough, it is easy to find online resources and tutorials to get your hands into non-core parts of the code. I am technically incompetent, but still I have been able to teach myself to tweak the CSS in a blog’s style sheet, and even the PHP code for very simple tasks, like assigning different headers to different page or inserting a line of Javascript. That required a small-ish investment, to which the proliferation of “For Dummies” books in my library is testimony. This gives you an incredibly important freedom: that of developing in a quick-and-dirty fashion, launching, and then just keep tweaking as your project evolves. Trust me, you will feel the need from day one.

Here’s the trick: the hackerish power admin role is perfect for a public servant that needs to procure software. Getting to know the architecture of these platforms well and to take full advantage of their scope for customization does not make you developer, but it does mean being able to have a constructive conversation with your developers, get real on what can and can’t be done, how long it takes and how much it costs. Furthermore, a power admin can rethink her goals in terms of the software, and so come up with highly sophisticated terms of service for the procurement effort. For example, on Edgeryders we need to constantly reinvolve users in the conversation: this is done through email notifications and the recent activity feed. In Drupal, these functionalities are carried out by certain non-core modules. If the public servant knows this, she can procure not “a website that feels buzzing”, but “a website in which the activity stream module logs activities that are not logged out-of-the-box”, that is much clearer

When I got into motorcycle riding, I read the obligatory Zen and the Art of Motorcycle Maintenance. The lesson of that book is the following: the act of driving a motorbike is not really separable from that of doing its maintenance. “Romantic” bikers, who do not enjoy getting their hands dirty, don’t accept this, and delegate to professional mechanics even the simplest maintenance operation. But they pay the price of disempowerment, when their machines stop by the roadside and won’t get started again, and they don’t have a clue what’s wrong and how to fix it. This system failure can be disastrous in public policy: in the projects I manage technology typically accounts for less than 10% of the budget, yet if the technology is not there the entire project grinds to a halt.

Summing up, high quality procurement is impossible until you know what you are buying. In my experience the free/open source software community is up for sharing its knowledge; corporates producing proprietary software much less so. If, like me, you find yourself in the position of procuring a simple technological solution for the public sector, I recommend you turn to this community, arm yourself with patience and get your hands dirty with the technology the developers intend to use. Install and configure sandbox sites, add functionalities, tweak their look and feel. Spend time with hackers, show that you are eager to learn, an grill them with questions. Above all, don’t yield to the temptation of going “this is not my job, just make it work and send me the invoice”. It doesn’t work like that. This is very time consuming, but you will save that time, with interests, once you are in production. I know it’s not a perfect system, but it is still better than available alternatives. Truth be told, I think it would be really useful if somebody started a course of website procurement for public servants. Anybody out there is interested? I would certainly sign up.

Thanks Freddy Mascheretti, Ivan Vaghi, Paolo Mainardi and Claudio Beatrice for their patience and suggestions

16 thoughts on “Zen and the art of website procurement: why bureaucrats should get their hands dirty with technology

  1. Marco Camisani Calzolari

    Ning è Platform as a Service, non Software as a Service. Pare un sofismo ma il SaaS è roba che gestisci tu anche se offerta come servizio. Mentre il PaaS è di terzi e quindi paghi pegno come da te descritto…

    Reply
    1. Alberto Post author

      Grazie della precisazione, Marco. Il lock-in del fornitore è comune a entrambe le formule, mentre il lock-in del database accade solo con PaaS.

      Reply
  2. Renato Turbati

    Ciao, ti perseguito seguendoti ovunque. Il mio gruppo di lavoro che è composto da me (sociologo di formazione, valutatore professionista con competenze in metodologia della ricerca e supporto alla governance di progetti complessi), un prof. universitario di statistica con competenze informatiche spiccate e uno statistico con competenze informatoche significative e di metodologia della ricerca dal punto di vista statistico altrettanto significative, abbiamo sviluppato più che un SW una cosa che noi abbiamo chiamato sistema che permette di mettere insieme le funzionalità della macchina e la competenza delle persone. Esattamente lo sporcarsi le mani che tu intendi spalmato su tre teste che lavorano all’unisono per dare al cliente la miglior soluzione possibile. Quello che abbiamo creato funziona alla perfesione ormai da due anni ed è sempre in evoluzione. Se trovi/troviamo soggetti pubblici interessati a capire come si usano cose del genere e a cosa servono, io/noi siamo a disposizione per partecipare e far conoscere la nostra “invenzione” finalizzata a monitorare e valutare policy, programmi, progetti anche di grande e grandissima entità, ma non necessariamente.

    Reply
  3. Tito

    Ciò che scrivi è molto utile. Tradotto nel mio linguaggio significa anche per me molto lavoro in più come committente di sistemi di dialogo tra amministrazione e privati individui. Però mi convince anche, perchè, superati (momentaneamente e temporaneamente) i costi di acquisizione di competenze, questo farebbe di me un gestore di poltiiche pubbliche molto più forte e autonomo.

    Reply
  4. Claudio Beatrice

    Buon articolo, si capisce che è stato “vissuto”.
    Non è la prima volta che mi capita di vedere una persona camminare su questo percorso o uno simile: la pratica dell’ “outsourcing totale” molto raramente paga ed infatti si capisce che sei arrivato con l’esperienza a percepire la necessità di un metodo di sviluppo di progetto differente, che probabilmente si sposa bene con ciò che gli addetti ai lavori chiamano “agile”, che tra le altre cose prevede la partecipazione attiva del cliente(senza pretendere necessariamente la presenza di power user, chiaramente).
    Non so se l’hai già visto, ma probabilmente riconoscerai certi valori nel manifesto: http://agilemanifesto.org/

    Ciao e grazie ancora della citazione! 😉

    Reply
    1. Alberto Post author

      Conoscevo lo sviluppo agile via un’amica, che ne è entusiasta. Da quello che ho capito, ciò che i grandi corporates chiamano “sviluppo agile” nel mio mondo è lo stato di default. Grazie a te!

      Reply
  5. Salvatore Marras

    Una riflessione e una prospettiva interessante!
    Sulla base di pensieri molto simili alcuni anni fa è nato http://www.innovatoripa.it. Uno spazio per gruppi e comunità che nascono nella PA italiana. Quando abbiamo iniziato a disegnarlo è stato naturale copiare le caratteristiche di ning e facebook, ma anche di http://www.fainotizia.it/.
    InnovatoriPA è sviluppato con Drupal ed è disponibile per tutte le PA che ne facciano richiesta.
    Stiamo per fare una revisione e un aggiornamento su Drupal 7, forse potremmo condividere qualche idea, funzionalità o modulo…
    Buon lavoro!

    Reply
    1. Alberto Post author

      Sono anche un utente di innovatoripa, anche se non lo uso da un bel po’.

      Volentieri, parliamoci! Chi sviluppa per voi? Vi va di collaborare su Edgeryders?

      Reply
  6. Freddy

    Ma prego…. 🙂
    So che ho ancora un lavoretto in sospseso da sistemarti…lo so…lo so… 😉
    non posso che essere d’accordo, i software/servizi “black box” sono tanto semplici quanto pericolosi se ci appoggi sopra la tua attività/servizio/sito/.
    Ultimamente mi sono cimentato timidamente con un sito di e-commerce, e il fatto di avere il controllo completo di tutto il contenuto del sito e del db non ha pari.
    Basta un backup e se cade l host o emigra sulla luna, in mezz’ora lo ripristino dove voglio.
    (per che fosse interessato, sto usando PrestaShop come piattaforma)

    Reply
  7. Christoforos Korakas

    Ciao Alberto

    Being my self in the position of the publict sector (even if not a public servant) sollution buyer, I agree with your points and rely myself on opensource sollution (Drupal) hosted in the Public Sector Infrastructure

    Your Idea of getting your hands dirty goes very much along what I heard in one of the sessions in Drupalcon Chicago: the more and the earlier Project managers get involved deep in technology and design decisions the better for the project.

    I agree with the procurement fiasco in Governement being all to often the case that the Governement itself doesnt have a clue or doesn’t want to have a clue on the technology and sollution it is buying leaving this decision either to external consultants or even to the company providing the sollution with results that are far from optimal in most of the cases.

    I agree also that the opensource community has a better starting point to finding a sollution vs the company that is relying on its sollution / software to make its profit and that will try to sell it to you and lock you in it as soon as possible.

    Nevertheless from my experience the opensource / Drupal development doesnt come cheap either in terms of man/hours spent. Once you need to provide deeper and finer functionality and you need to tweek the user interface to provide decent UX to users to drive adoption, you will need to get top class experienced developpers that will know how to do the trick and bend Drupal to fit your needs while keeping it portable to the next version of Drupal.

    Actually the cost of doing a deeply customised Drupal website is probably the same as building it from scratch without Drupal. The undeniable advantage being nevertheless the possibility to tap into the sea of modules and functionality tweaks provided by a large community and the relative independence from your software developers. A good drupal project can be transfered to a new (as competent) team without them havingto spend weeks trying to understand what the previous team wanted to do.

    I also agree with the software as a service limitations, but only in the case of the private clouds out there that pretend to be public.
    Indeed a really public cloud is needed to make sure all this community energy invested on there is not hijacked by any private company that used honey-pot tacktics to then lock-in and convert free users to unhappy paying customers.

    A public sector cloud (internally hosted in gov infrastructure) is also a crucial evolution point in the future of e-governement and the much needed digitisation of internal workflows and business processes and internal knowledge sharing. Too much of it still relies on just shared folders, word, excell and outlook.

    Chris

    Reply
    1. Alberto Post author

      Thanks for your insights, Chris. Given your experience in the field, they are really invaluable.

      I fully agree we need a solid public sector cloud. While we are at it, I would add some public social web infrastructure. At that point, software-as-service would indeed look like an attractive solution.

      My position on the “tweaking Ux” issue is a little more nuanced. You are clearly right when you say Drupal is famously difficult to submit to fine-tuned control. And yet, I am a little skeptical of Ux itself: somehow, it seems to be the computer version of advertising. Its philosophical assumption is that there is someone out there called “a user”. He/she is stupid, uninterested, and has a very limited attention span. He/she should not be trusted to use a piece of software responsibly. You, the person in charge, has to make it problem-free for them.

      This is not wrong. But I wonder if it might be a self-fulfilling prophecy, like Taylorism in manufacturing or advertising in communication. In those cases, designing for a dumb user actually made users dumb. Drupal projects can be quite a bit cheaper than fully customized ones if you work from the technology core outwards, instead of starting from the Ux. Essentially, what you are saying is “hey, user! This is a piece of software. Help us keep costs down by taking on some responsibility for managing its complexity.” Would not this kind of thing produce a faster, more efficient human/machine system in the medium run?

      Reply
  8. Luca

    Ciao Alberto,
    ottimo post, pienamente condivisibile. Ne abbiamo twittato, la proposta è: riusciamo a farne diventare un’azione per l’agenda digitale di Bologna Iperbole2020?
    Luca (@capitanachab)

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.