Developer conferences are a great way to re-energise yourself and your work with new ideas, partly thanks to the content from the front, and partly because you get to engage with other developers. Technology changes constantly; but if I reflect on events I have attended I notice some common themes. Occasionally there are compelling technical insights - I think of the first time I heard Ryan Dahl describe the thinking behind Node.js, for example - but more often the most acclaimed talks are not about technology as such. Rather, they are about how we work together: communication, and simple truths about human nature.
This proved the case again at the Monki Gras recently, an unusual London event run by analysts Redmonk.
Craig Kersteins and Matt Thompson from Heroku asked a question: how often are you interrupted at work? Software development is partly about keeping a lot of information in your head so that you can see patterns and make connections, and avoid bugs by remembering exactly how the code you are working on fits into the application. Getting a summons to a meeting or a call from a colleague in the midst of that kind of concentration is costly. They even put a figure on it. 76% of the worst-performing engineers are frequently interrupted, they said.
How often is frequent? That was not stated; but they did suggest aiming for 4 hours of uninterrupted work each day. That still leaves plenty of time for meetings; and I have little doubt that 4 hours of good work counts for more than 8 hours of choppy work that leaves you feeling that you should not have bothered to turn up.
More human factors: Mazz Mosley and Nick Stenning from the UK Government Digital Service advised us not to recruit "rock star" developers who become a single point of failure, as everything stops if they become unavailable. A team with collective intelligence is better.
Ted Nyman from GitHub weighed into managers. They do not have any. I was reminded of a comment from Joyent's Bryan Cantrill at Monki Gras 2012: "it is very hard for middle management to add value".
Do I think that most companies remove all their managers? That is neither realistic nor likely to succeed. As another attendee observed, companies with managers generate a lot of revenue.
The point though is this: the way developers are managed impacts their productivity. That human factor matters more than whether they use Java or C#, or which tools they use.
I hear similar insights from the QCon conference in London each year. Coming up in March and recommended.
Shanley Kane from Basho spoke about honesty in software development. Roadmaps are a lie, she claims, because attempts to map features to a timeline will always fail. When roadmaps fail that erodes trust in the team. Interactive "what we're working on" documents work better, she said.
I will leave the last word to Cyndi Mitchell from Logscape and Thoughtworks, who remarked at Monki Gras that "Software is fundamentally a human, interactive activity. If you don't understand that, forget it."
Gil Zilberfeld, an agile practices expert, has posted on 4 warning signs that Agile is declining. I will not re-iterate his points; you should read the article for yourself. The overall theme though is this. The software establishment - including the managers, the consultants, the trainers, the vendors - has embraced Agile, to the extent that, according to Zilberfeld, more than half of software projects at least nominally use Agile methods. The results are disappointing though, because companies have simply absorbed bits of Agile into their existing top-down management culture. Therefore:
At this point, I feel Agile is declining into what TQM [Total Quality Management] was. A brilliant success in the beginning, and now just a history fact. In a few years, months even, the business side will wake up and say: Agile is snake oil. It doesn't deliver on its promise (and it doesn't matter if it's done wrong). The backlash will be grand.
I am reminded of something I learned from one of the excellent QCon conferences in London, which covers Agile in depth. It was not so much a specific speaker or talk, more a common theme running through many presentations. Software projects generally do not fail for technical reasons. They fail because the team - using the word team in its widest sense, to include all project stakeholders from users to executives - fails to communicate effectively. Many Agile techniques, such as the daily meeting which is part of the Scrum methodology, are designed to facilitate communication. I have also heard recommendations such as moving developers into the same office as managers in order to get them talking to each other. Another example, at a micro level, is Pair Programming, where two developers work side by side on the same code. You cannot do this without communicating your intentions, ideas and solutions to the person alongside you.
Kent Beck, one of the pioneers of Extreme Programming and Test Driven Development, highlights the human factor in software development. Take a look, for example, at his essay on Accountability in Software Development:
... while programming I offer accountability as a way of demonstrating my trustworthiness and encouraging my own best behavior. Pair programming; test-first programming; continuous integration; visible daily, weekly, and quarterly cycles; slack; and estimation are some of the way I make public commitments and render account of my activities. Knowing I will be honest and accountable affects how I do my work, just as knowing that I am hiding and concealing negatively affects how I do my work. Taking responsibility for my choices and actions deflects blame. There is no hidden shame if everything I do is above board.
What is important here is not the techniques in themeselves, but the trustworthiness and accountability they facilitate.
Human problems are harder to solve than technical problems, and seen in this light it is not surprising that companies which adopt bits of Agile methodology without changes in corporate and management culture will miss out on most of the benefits.
Another common experience at software development conferences is to talk to developers who enthuse over the insights they have received, but then lament that they cannot be applied in their workplace. The reasons are old and familiar: inflexible management, longstanding broken processes that nobody seems able to fix, little kingdoms which protect their borders at the expense of the effectiveness of the whole corporation, and so on.
A few thoughts in conclusion. First, if Agile projects are failing, that does not necessarily imply that something is wrong with Agile methodology. It all depends on how it is done and whether the people involved are embracing or resisting the change and communication that goes along with it. Second, irrespective of the methodology, effective communication is key to the success of a project; and if it is not possible to change the methodology or even the tools and technology, working on team communication may still yield amazing results.
Velocity changes are not good or bad, they are. And, if you track velocity, you will have more information about the team's progress.
I particularly like to track velocity as a burnup chart.
I'm just back from Adobe's partner conference in Amsterdam, where George Neill, Lead Experience Architect at Adobe Consulting, shows us this great slide depicting a woman processing mortgage applications. She has a PC on her desk which is running her organisation's app for managing mortgage applications. However, around here desk are multiple signs of usability failure. On her left, a paper calendar with names and phone numbers handwritten onto deadline days. On her right, an old-fashioned paper roll calculator. In front of her, a pile of paper forms colour coded with post-it notes. The app, Neill notes, should be handling all these tasks, but one glance at the user's working process is sufficient to expose its poor design.
All good stuff. The next thing we see is a nice application built with an Adobe Flex front-end and an Adobe LiveCycle back-end, with the not-so-subtle implication that these user-experience (UX) focused tools will help us create applications that fix this kind of design failure. There's also talk here at Adobe's partner conference of a new era in software built on customer experience, and how consumer technology from iPhone to Facebook and Twitter is raising expectations when it comes to business applications. There are even a few digs at developers, the people who, it is alleged, hate it when requirements change and who develop software geared towards the IT system which which it integrates, rather than towards users.
There is truth in all of this, but I'm cautious. It is easy to find a poor application and poke fun at it, but the idea of observing users and creating applications that improve their productivity is not a new one, and it is not necessary to use Adobe's stuff in order to do good software design. There are even times when it gets in the way. I recall spending time looking for a campsite on the web, for a holiday, and how it was in general the simple HTML sites rather than the "rich" Flash-driven ones that were easier to navigate. Admittedly the average campsite does not create web applications to Enterprise standard, but the underlying point is that there is a case for simple as well as a case for rich. Never forget "skip the intro".
The key question here: how do we define excellence in user experience? Let me state the obvious for the moment.
Applications that have functional deficiencies will not be rescued by any amount of eye candy or beautiful state transitions; and if the user is surrounded by post-it notes and antique calculators I'd suggest that this is not primarily a UX issue, unless we strip all meaning from the term and use it for every aspect of software design, features and performance.
Second, software can deliver a good UX without necessarily having gorgeous graphics and multimedia. As a business software user, I value applications that let me accomplish tasks quickly and easily. Question: think of a web application that changed the world, partly thanks to superb UX? Answer: Google search. Question: how much PhotoShop and Flash was used in designing the fantastic Google home page?
The case for user-centric software design is irrefutable; but we need rigour when it comes to working out what that means and how to achieve it. I like this comment which I found in an 2004 paper by Larry Constantine:
User-centered design is a good idea in need of improvement. The needed improvement is found in practices that put uses rather than users at the center of design and in changing the prime objective from enhancing user experience to enhancing user performance.
UP rather than UX resonates with me. It also reminds me of Kathy Sierra's mantra: creating passionate users. If the current rush towards UX puts the focus there, I am all in favour. If it means newly empowered designers imposing some sort of visual or multimedia experience on us whether we like it or not, count me out.