| Andrew Cooke | Contents | Latest | RSS | Twitter | Previous | Next

C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Lepl parser for Python.

Colorless Green.

Photography around Santiago.

SVG experiment.

Professional Portfolio

Calibration of seismometers.

Data access via web services.

Cache rewrite.

Extending OpenSSH.

C-ORM: docs, API.

Last 100 entries

Maths Books; Good Bike Route from Providencia / Las Condes to Panul\; Iain Pears (Author of Complex Plots); Plum Jam; Excellent; More Recently; For a moment I forgot StackOverflow sucked; A Few Weeks On...; Chilean Book Recommendations; How To Write Shared Libraries; Jenny Erpenbeck (Author); Dijkstra, Coins, Tables; Python libraries error on OpenSuse; Deserving Trump; And Smugness; McCloskey Economics Trilogy; cmocka - Mocks for C; Concept Creep (Americans); Futhark - OpenCL Language; Moved / Gone; Fan and USB issues; Burgers in Santiago; The Origin of Icosahedral Symmetry in Viruses; autoenum on PyPI; Jars Explains; Tomato Chutney v3; REST; US Elections and Gender: 24 Point Swing; PPPoE on OpenSuse Leap 42.1; SuperMicro X10SDV-TLN4F/F with Opensuse Leap 42.1; Big Data AI Could Be Very Bad Indeed....; Cornering; Postcapitalism (Paul Mason); Black Science Fiction; Git is not a CDN; Mining of Massive Data Sets; Rachel Kaadzi Ghansah; How great republics meet their end; Raspberry, Strawberry and Banana Jam; Interesting Dead Areas of Math; Later Taste; For Sale; Death By Bean; It's Good!; Tomato Chutney v2; Time ATAC MX 2 Pedals - First Impressions; Online Chilean Crafts; Intellectual Variety; Taste + Texture; Time Invariance and Gauge Symmetry; Jodorowsky; Tomato Chutney; Analysis of Support for Trump; Indian SF; TP-Link TL-WR841N DNS TCP Bug; TP-Link TL-WR841N as Wireless Bridge; Sending Email On Time; Maybe run a command; Sterile Neutrinos; Strawberry and Banana Jam; The Best Of All Possible Worlds; Kenzaburo Oe: The Changeling; Peach Jam; Taste Test; Strawberry and Raspberry Jam; flac to mp3 on OpenSuse 42.1; Also, Sebald; Kenzaburo Oe Interview; Otake (Kitani Minoru) move Black 121; Is free speech in British universities under threat?; I am actually good at computers; Was This Mansplaining?; WebFaction / LetsEncrypt / General Disappointment; Sensible Philosophy of Science; George Ellis; Misplaced Intuition and Online Communities; More Reading About Japan; Visibilty / Public Comments / Domestic Violence; Ferias de Santiago; More (Clearly Deliberate); Deleted Obit Post; And then a 50 yo male posts this...; We Have Both Kinds Of Contributors; Free Springer Books; Books on Religion; Books on Linguistics; Palestinan Electronica; Books In Anthropology; Taylor Expansions of Spacetime; Info on Juniper; Efficient Stream Processing; The Moral Character of Crypto; Hearing Aid Info; Small Success With Go!; Re: Quick message - This link is broken; Adding Reverb To The Echo Chamber; Sox Audio Tools; Would This Have Been OK?; Honesty only important economically before institutions develop; Stegangraphy via PS4; OpenCL Mess

© 2006-2015 Andrew Cooke (site) / post authors (content).

Reflections on First Consultancy Gig

From: "andrew cooke" <andrew@...>

Date: Mon, 8 Jun 2009 14:51:37 -0400 (CLT)

I finished my first job in the capacity of a "consultant" and have been
thinking about how it went (ie worrying over the problems).

Technically, things generally went well.  I perhaps didn't worry enough
(or early enough) about efficiency, but this is perhaps more a social
issue than a technical one: even if you know a system can be made quick
enough in later iterations, "it's slow" is an immediate reaction of anyone
who tries it.

The technical/social distinction continues to be misleading, because my
first social issue is also a technical one: that I didn't think about the
future of the system.  Who will maintain and run it?  And do they have any
interest in it succeeding?

Related to that, did I provide what the client wanted?  I am not sure I
did.  There was an existing application that looked very good, but had a
poor technical basis.  I developed a new system that provided the
technical infrastructure on which a replacement could be built (or to
which the existing system could be moved).  That's fine, technically, but
it would have been much better received, I think, if it had been
implemented as a progressive extension to the existing system.  An
adaptive approach like that would have had the following advantages:

- The final result would integrate the existing presentation layer, which
looked good.

- During development I would have seen "real life" loads from the upper
layer, which might have led to slightly different (efficiency related)
implementation choices.

- The process for supporting the existing system would have adapted
gradually to the new system.

So why didn't I do this?  One obvious reason is that it sounds like a lot
more work.  But it turned out that we had enough time to implement much
more than anyone originally hoped.  So, at least in retrospect, I could
have taken much longer - half the functionality, better received, would
have been a decent tradeoff.

Another reason is that there was both poor communication and a fear of
poor communication.  The approach sketched above requires good
communication, I think.  But perhaps pressing forwards would have improved
communication to the degree necessary?  It is hard to argue against the
alternative - that by striking out alone, I made communication even worse.

All above is particularly galling because, while I don't think I am the
world's greatest communicator, I do think I am aware of my limitations and
sensitive to the kinds of issues described above.  I was certainly aware
of problems half-way through, when we gained an extension for more work;
at that point I knew I was not involving the client, but had not grasped
the extent of the problem.

While my *internal* process might be described as agile - many small
cycles, code always close to deployable, etc - I failed to implement what,
to me at least, seems to be agile's greatest tool: client participation. 
And the key to client participation, in this case, would have been
adaption of the existing system.

Andrew

Comment on this post