Tag Archives: technology

Programming

Authenticity and appropriation

I know I’m not a hacker, I don’t describe myself that way and I know its not what I do. I may indulge in hacks of both programming and other kinds but hacks do not make the hacker.

“Hack” and its derivatives are very popular though. “Hackdays”, prototypes getting described as “hacks”, and people self-identifying as “hackers”. Learning something in 24 hours is old hat now, why not just “hack” it instead.

This kind of wholesale appropriation of sub-culture is nothing new. Look at punk, hip-hop or skateboarding. In a way this theft of technologist’s jargon is a backhanded complement, a validation of its worth and validity.

Appropriation brings with it the question of authenticity. Authenticity brings with it the whole field of identity politics. It is a cascade of events that brings us to point where arguments erupt as to who is capable of determining who is truly a “hacker”.

Until recently I didn’t feel this argument has effected me very much. Since I have an instinct for people who meet the archetype of the hacker (by trade) and I don’t seek the title for myself it has felt like a fight I don’t have a dog in.

The latest wave of hacker appropriation renders a useful concept useless. As a good post-modernist I don’t weep for the hacker. The thing about all appropriated sub-cultures is that if they are going to thrive they are going to evolve; change, renew and protect themselves. Witness the rise of the “brogrammer” as way of delineating those inside and outside the tent.

However when I hear the accusation that authenticity in technology is a matter of white male privilege rather than an attempt for a community to express and recognise an identity, I think we have an argument that seems to serve no-one very well.

I’m not saying that technology communities aren’t sexist or male-dominated. They self-evidently are. Unlike a lot of communities, though, technology is something where a meritocracy can function. While meritocracies are clearly shaped by peer pressure and conventional wisdom the simple fact is that a programmer is going to evaluate the utility of a piece of code entirely on how well it serves their own needs and not the gender of the person who wrote it. In fact in an internet world of handles and shared code the real identity of the person you collaborate with is often unknown to you, an irrelevance.

“Good code” is a cultural artefact, shaped by the constitution of the community. Useful code is not.

Appropriating hacking may seem a good idea. But when you do it, dismissing criticism of the authenticity of the result is self-defeating. Anything appropriated is devalued.

Attempting to liberate or seize control of the language of technologists might seem a good idea in the name of a diverse community. But anything done without consent will result in resistance.

Let’s tackle sexism and exclusion by all means, particularly in user groups and conferences where identity is concrete.

But let’s not think that cultural politics can substitute for code contributed to and valued by the community. Let the work speak for the individual, let’s value utility, humility and modesty more than any one disputed signifier.

Standard
Software, Work

Up-front quality

There has been a great exchange on the London Clojurians mailing list recently talking about the impact of a good REPL on development cycles. The conversation kicks into high-gear with this post from Malcolm Sparks although it is worth reading it from the start (membership might be required I can’t remember). In his post Malcolm talks about the cost of up-front quality. This, broadly speaking, is the cost of the testing required to put a feature live, it is essentially a way of looking at the cost that automated testing adds to the development process. As Malcolm says later: “I’m a strong proponent of testing, but only when testing has the effect of driving down the cost of change.”.

Once upon a time we had to fight to introduce unit-testing and automated integration builds and tests. Now it is a kind of given that this is a good thing, rather like a pendulum, the issue is going too far in the opposite direction. If you’ve ever had to scrap more than one feature because it failed to perform then the up-front quality cost is something you consider as closely as the cost of up-front design and production failure.

Now the London Clojurians list is at that perfect time in its lifespan where it is full of engaged and knowledgeable technologists so Steve Freeman drops into the thread and sensibly points out that Malcolm is also guilty of excess by valuing feature mutability to the point of wanting to be able to change a feature in-flight in production, something that is cool but is probably in excess of any actual requirements. Steve adds that there are other benefits to automated testing, particularly unit testing, beyond guaranteeing quality.

However Steve mentions the Forward approach, which I also subscribe to, of creating very small codebases. So then Paul Ingles gets involved and posts the best description I’ve read of how you can use solution structure, monitoring and restrained codebases to avoid dealing with a lot of the issues of software complexity. It’s hard to boil the argument down because the post deserves reading in full. I would try and summarise it as the external contact points of a service are what matters and if you fulfil the contract of the service you can write a replacement in any technology or stack and put the replacement alongside the original service.

One the powerful aspects of this approach is that is generalises the “throw one away” rule and allows you to say that the current codebase can be discarded whenever your knowledge of the domain or your available tools change sufficiently to make it possible to write an improved version of the service.

Steve then points out some of the other rules that make this work, being able to track and ideally change consumers as well. Its an argument for always using keys on API services, even internal ones, to help see what is calling your service. Something that is moving towards being a standard at the Guardian.

So to summarise, a little thread of pure gold and the kind of thing that can only happen when the right people have the time to talk and share experiences. And when it comes to testing, ask whether your tests are making it cheaper to change the software when the real functionality is discovered in production.

Standard
Work

Agile software development defers business issues

My colleague Michael Brunton-Spall makes an interesting mistake in his latest blog post:

much of our time as developers is being completely wasted writing software that someone has told us is important.  Agile Development is supposed to help with this, ensuring that we are more connected with the business owners and therefore only writing software that is important.

Most Agile methodologies actually don’t do what Michael says here. Every one I’ve encountered in the wild treats it as almost axiomatic that there exists someone who knows what the correct business decision is. That person is then given a title, “product owner” for example and then is usually assigned responsibility for three things: deciding what order work is to be done, judging whether the work has been done correctly and clarifying requirements until they can be reduced to a programming exercise.

That’s why it was liberating to come across System Thinking which does try to take a holistic approach and say that any organisation is only really as good as its worst performing element. Doing that does not eliminate all the process improvements in development that Agile can provide but also illustrates that a great development team doing the wrong thing is a worse outcome than a poor development team doing the right thing.

The invention of the always correct product owner was a neat simplification of a complex problem that I think was probably designed to avoid having multiple people telling a development team different requirements. Essentially by assigning the right to direct the work of the development team to one person the issue of detail and analysis orientated developers getting blown off-course by differing opinions was replaced by squabbling outside the team to try and persuade the decision maker. Instead of developer versus business the problem was now business versus business.

Such a gross simplification has grave consequences as the “product owner” is now a massive point of failure and few software delivery teams can effectively isolate themselves from the effects of such a failure. I have heard the excuse “we’re working on the prioritised backlog” several times but I’ve never seen it protect a team from a collectivised failure to deliver what was really needed.

Most Agile methodologies essentially just punt and pray over the issue of business requirements and priorities, deferring the realities of the environment in the hoping of tackling an engineering issue. Success however means to doing what Michael suggests and trying to deal with the messy reality of a situation and providing an engineering solution that can cope with it.

Standard
Work

Silicon Milkroundabout Roundup

Interesting time at Silicon Milkroundabout this Sunday. There were kind of three levels of activity going on, first of all there was the element of developer goofing off with arcade machines and free stuff. Then there was the opportunity to network, first of all between the startups and secondly between the developers (although I am not sure how much mixing between different dev teams was actually going on).

Finally there was the recruitment activity. Unlike the first event this really was more of a milkround with a younger, less experienced audience. The format did seem to be pitching for talent which is interesting as I am not convinced that people are going to find the best role by going with the best sales pitch. There has to be a better way of understanding the culture of the firm you are potentially joining.

The different streams of activity make the event quite weird in its nature and purposes. It feels like there is a need for a kind of startup expo to allow startups to see and meet one another without the pretext of seeking to employ people. There is also a need for a kind of elite coder event on a quarterly basis that is maybe a little select, a bit like a mini-conference, that allows for networking and swapping of intelligence and gossip on what is really going on at various firms.

Standard