As a Team Lead in a fairly talkative organisation, I attend a lot of meetings. However valuable these discussions may be, this presents a couple of challenges for the team.
Continue reading “Be more transparent about your meetings: put them on the board”
I shared yesterday’s post with some friends, who were keen to explore what we mean when we talk about creativity in software development.
Alastair made an interesting comment:
…it made me reconsider software dev as a creative endeavour, but I think I came to the conclusion that it is. For me, I think there is a gap between a creative art like writing, especially one which has an expressive mirror like acting, and a purely creative activity like, e.g., whittling a stick or constructing a building.
I think there is value in disentangling our concepts of creativity, and I find Alastair’s distinction between the creative arts and simpler forms of creation very useful.
There’s also an ambiguity in the word ‘create’, as it can refer simply to making things, as well as to the creative endeavours we would like to characterise.
So rather than ask ‘Is software development a creative activity?’, I tend to consider a narrower question: ‘Is there a place for creative thinking in software development?’
As the most basic level, I see creative thinking as making new links between concepts. Once you have made the link, you can engage other thought processes, for example deductive thinking, to explore the consequences and implications of that link.
But because the link isn’t already there, you can’t find it by rational thought; you need a leap of imagination to reach it.
There are some sorts of problem that I can tackle best once I’ve slept. On a few lucky occasions I’ve been able to take an afternoon nap, and woken up with a new idea to investigate, but this usually means taking the idea home with me and letting it brew overnight.
Here are a few examples of problems in software development that can be tackled with creative thinking:
And of course, because software development in an organisation is a social activity, the need for creative thinking extends far beyond the design of the software.
There‘s an idea in certain circles that we should be able to bring our whole selves to work.
There are aspects of this notion that I find unproblematically wonderful. For those of us who are invisible members of minority groups, the ability to drop the mask and be open about our identities can help us find a level of safety and inclusion at work.
There are areas that I find problematic, particularly questions about how permeable the work/life barrier should be. These are questions for another day.
The point I’m thinking about today is that there are aspects of all of us that are unpleasant. We think dark thoughts and entertain transgressive fantasies. These are parts of our whole self, but do we really want to bring them to work?
Carl Jung characterises this aspect of us as our Shadow, and sees our encounters with our Shadow as part of the way we Individuate ourselves. Repression and denial of the Shadow can lead to dysfunction: we can become overwhelmed by it and start Acting Out our fantasies, rather than enjoying them in the privacy of our mind.
So I find a tension here: being a psychologically healthy person requires us to have a healthy relationship with the dark areas of our minds, to admit these areas into our whole selves. But if we are to bring our whole selves to work, then we need to bring these dark areas to work as well.
This question becomes more pressing if we accept that there is a close relationship between our Shadow and our creativity. If we hope to do creative work, then we need to be able to dip our bucket into this dark well.
In this context, I read something interesting in an interview with Phoebe Waller-Bridge:
More than anything, she says, as a writer she wants to show women indulging their appetites and venting their grievances. “We sexualise women all the time in drama and TV. They are objectified. But an exploration of one woman’s creative desire is really exciting. She can be a nice person, but the darker corners of her mind are unusual and fucked up, because everyone’s are.” Has she always been able to say the unsayable? “Yes. As long as it feels truthful, as long as it’s pointing at the elephant, it is always exciting.” [Emphasis mine]
And this got me thinking again: Waller-Bridge is making quite a name for herself by bringing the darker corners of the mind, the Shadow, into her work. As a screenwriter this may be rather more straightforward than for a software developer, for example. But is there a way we can openly and honestly bring these aspects of ourselves to work? Is a truly psychologically safe workplace one where we can invite our Shadows?
At 7digital we have 2 days’ innovation time every month. During this time we can work on our own pet projects. This post is about my current project.
You can find the source of this project at https://github.com/bnathyuw/Hateoas-Console
RESTful web architecture is becoming increasingly influential in the design of both web services and web sites, but it is still very easy to produce half-hearted implementations of it, and the tools that exist don’t always help.
In this project, I want to address this problem by building a new REST console that will:
Richardson and Ruby (2007 pp. 79 ff.) present a good analysis of RESTful interface design. Drawing on Fielding (2000 s. 5), but with a focus on actual practice, they identify four key principles or Resource-Oriented Architecture:
Addressability means that any resource in the application that a consumer could want to know about has at least one URI. This criterion is fairly coextensive with Fielding’s Identification of Resources requirement.
Statelessness means that every request should contain all the information needed for its processing. This overlaps with Fielding’s requirement that messages be self-descriptive, and that hypermedia be the representation of application state.
Connectedness means that each resource representation should give addresses of all related resources. The most effective way to ensure connectedness will often be to produce an entry-point resource, from which it is possible to navigate to all other resources. This furnishes the other part of Fielding’s requirement for hypermedia as the engine of application state.
Uniform Interface means that all resources can be manipulated in the same way. For web services, this almost invariably means using the HTTP verbs, viz DELETE, HEAD, GET, OPTIONS, POST, PUT &c. This principle supports Fielding’s self-description criterion, and specifies the means of manipulation of resources.
Most REST consoles are fairly successful in accommodating principles 1, 2 and 4, but fail significantly in accommodating principle 3. Under Fielding’s terminology, existing REST consoles give little support for hypermedia as the engine of application state (HATEOAS).
There exist several good consoles for manually consuming RESTful services. These include:
All of these clients work on a similar model: you enter a URI in the address box, choose an HTTP verb and click a button to send the request. You also have the option of adding headers and a request body. The headers and content of the response are then displayed on screen for the user to inspect.
Addressability is a core notion in these consoles: the address box is a primary part of the UI, and you have to enter something here in order to make a request.
Statelessness is perhaps the easiest of the four principles to achieve, as the consoles operate on a request-response model.
In fact, what is useful in a console is the very opposite of statelessness: the console should be able to remember your preferences so that you do not have to enter them for each request.
With a significant exception discussed below, all three consoles do a fair job of remembering your choice of headers from one request to another, which takes some of the burden off the user. Apigee and REST Client for Firefox are also able handle OAuth authentication, which is a nice feature.
None of the consoles deals successfully with connectedness. If you want to follow a link from the response, you have to copy the resource URI into the address box and submit another request.
Apigee differs from the other two consoles in having a side panel which lists the principle URI schemata for the service under test. This initially seems like a helpful feature, but has several unfortunate consequences:
me/favourites/track_id (PUT), it enters https://api.soundcloud.com/me/favorites/{track_id}.json in the address box. You then have to replace {track_id} with the specific track ID you are interested in. This is of course no help if you don’t know which track you want to add to your favourites!.json suffix, no matter what format you have just requested. Also, any request headers you have filled in are forgotten when you click on a new endpoint.These shortcomings not only make the console frustrating to use, but also encourage non-connected, RPC-style architectural decisions.
As with Addressability, the Uniform Interface is at the core of these consoles. The HTTP verb selector is prominent in each UI, and it is easy to switch from one to another.
Apigee supports GET, POST, DELETE and PUT, Simple REST Client for Chrome adds support for HEAD and OPTIONS, and REST Client for Firefox adds support for TRACE, as well as several more obscure verbs.
What none of these consoles does is make any attempt to figure out what representation of a resource should be submitted in a POST or PUT request body. This is particularly surprising in Apigee, as this information should be available in the API WADL document.
There are close points of comparison between a REST console and a web browser: each is designed to make requests from a particular URI using one of a small number of HTTP verbs, and then display a representation of that resource to the user. What makes a web browser so powerful — and indeed was one of the founding principles of the internet — is that the user can click on links to get from one page to another. When you the primacy of the clickable link to the success of browsers it becomes all the more puzzling that REST consoles do not implement this functionality.
The purpose of this project is to attempt to address some of the shortcomings of the currently available REST consoles, while retaining their good features:
GET, POST, PUT, DELETE, OPTIONS, HEAD;PUT and POST requests;I decided to implement this project in HTML and JavaScript, as this seemed the most portable platform. I am working on the assumption that the finished product will be a chrome extension, as this lets me make some simplifying assumptions about the capabilities of the browser environment, and may also help solve some security issues.
Matthew Butt 