A decade is a long time in software development, especially in enlightened software development. Ten years ago, the eXtreme Programming book had just been written and the nascent Agile movement was yet to write its founding manifesto. A dozen years after first being published, Peopleware – Productive Projects and Teams by Tom DeMarco and Timothy Lister was already a good year into its second edition. Now, in 2010, it is no less relevant than it was when originally published.

The authors, by the time of the second edition’s release, were seasoned consultants with a rich experience in working with both flourishing and withering development teams. Their emphasis was intentionally not on software development but on development in general, since many of the core ideas propounded in the book were, while motivated by observations in the arena of software development, not restricted to this industry. It seemed that the concepts were applicable to any team involved in a thinking activity. Therefore, it does not seem unreasonable to ask whether these ideas and concepts have taken any root in development environments in the financial services industry.

On first impressions, the evidence does not seem to be very encouraging. Peopleware expounds considerable effort in discussing the merits (or lack thereof) of modular offices spaces, or ‘cubicle farms’. Financial developers often work in big, noisy open plan offices, close to the decision makers, but removed from the type of environment that allows them to work effectively. This may seem counter-intuitive: don’t open plan offices allow for more effective communication between employees, either on a conscious or subconscious level, that benefit the organisation as a whole? To some extent this is true, but at the same time, damage is inflicted. The key concept here is the one called flow, which DeMarco and Lister borrow from the Hungarian psychologist Mihaly Csikszentmihalyi: ‘Flow is a condition of deep, nearly meditative involvement. In this state, […] there is no consciousness of effort; the work seems to, well, flow.’ The word flow evokes the feeling you have when you are absorbed by the work you are doing, where you do not notice time passing, or hunger and thirst building up in you. Not only is a state of flow characterised by this level of immersion, it is also typified by a positive, energised state of mind, which means that employees are more happy and content during this phase.

According to DeMarco and Lister, this state does not kick in until you have been concentrating for at least fifteen minutes. This is important to consider: does an open plan office really allow for such levels of concentration? People walk by your desk all day, some of them stopping and having a chat or asking questions and giving assignments; phones ring all day long; the smell of your colleagues fragrant ‘al desko’ lunch is wafting over.  Also, open plan offices seem to promote banter. While this is a valuable process in socially integrating your employees, it is not by any stretch of the imagination the most efficient way to do this. In the end, distraction is the norm of the day. You are in the middle of a noisy channel, and while some of the information you pick up through osmosis is useful, most of it will not be. ^{Cockburn seems to have coined the term osmotic communication for this: ‘Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis.’ While this is seen by Cockburn as a beneficial concept, the potential downside should not be ignored.}

‘Also’, those familiar with agile practices might say, ‘is it not true that sitting with your clients is considered a good thing?’ Yes, as long as there is a mutual understanding of the nature of this relationship. A client that is committed to your project full-time will be in ‘concentration mode’ at the same time as the rest of the team, or can be easily whisked away from his desk by team members when his brains need to be picked for the moment. A client that is involved with the team he sits with only part of his time will be more difficult. His colleagues from other projects will wander over to his desk to ask questions and have lively discussions, all within your earshot. Or, he will pay occasional attention to the project you are doing for him, and interrupt with questions. The fact of the matter is that maintaining flow in the proximity of colleagues who do a lot of context-switching, that is, who go back and forth regularly between different activities, is increasingly difficult. An understanding of the concept of flow is important, coupled of course with a respect for the effectiveness of your colleagues, who are adversely affected when they cannot attain flow. ^{See for instance Dobson for evidence that distractions do not necessarily just come in the form of noisy offices and loud co-workers, but can also be planted as software defects by developers who do not take responsibility for their own work.}

What to do, however, when your team seeks distraction itself? ^{In his essay from the summer, Jamie wrote how a dynamic can push and pull financial engineers into and then back out of the client offices.  He called this oscillation ‘lunacy’.} By voluntarily moving close to the territory of those you work for but who do not allow you to work in sufficient peace, are you not sabotaging your own chances of productive work? The reason why people do this seems pretty simple actually. Often, the client of development teams in financial organisations are the prime revenue generators for the company. By moving close to them, we hope that some of the glory of their job and the recognition they get for it, both monetary and otherwise, rubs off on the team. Or, by sitting close to the client, and adapting their style of work, we achieve glory by association. This seems to be an adaptation of what DeMarco and Lister call the ‘High-Tech Illusion’:  ‘The widely held conviction among people who deal with any aspect of new technology that they are in an intrinsically high-tech business’. This concept seems to be applicable to the front office as well. Because you work directly or indirectly for the front office stars, you become a ‘quant’ by association, when the reality is that a lot of the work you do is not quantitative in nature, but rather development. Sadly, for those who pursue this, the commensurate upside is not theirs (reward), but the downside (a chaotic workplace that does little to improve efficiency) is. There can be a further asymmetry between the stars and the ‘quants’ who work for them. Sometimes the stars will just only interact with those who are sat close to them, and not with those sat further away, or even on a different floor or in a different building.

The applicability of DeMarco and Lister’s ideas does not stop at the office floor layout and general work environment. The front office is a fast paced environment where people need to react quickly to the reality of the moment. This environment almost by definition has a very short-term outlook. It is generally ill-suited to practice sustainable software development. As a developer, you will be expected to be at the beck and call of the client, no matter what task you are working on. Their chaos slowly becomes your chaos as well. In a short term focussed environment, emphasis will be lost on those practices of the software development trade that allow for long-term sustainability, things like refactoring, test-driven development or incremental design. You will give in to temptation to develop your software in technology that allow for quick fixes, but are not best suited for sustainability. Entropy in your product will grow, day by day. In the end, you are not only denying your client a robust product that will be easy to adapt and maintain, but you are also depriving yourself of a satisfying work experience. All that time fighting fires and providing patches to your product could have been spent on improving it. The consequence here is both reduced productivity as well as demotivated employees. Incidentally, Csikszentmihalyi’s research into flow shows that it is more difficult to attain when the task you are working on does not sufficiently challenge or motivate you for your given skill level, suggesting that there is second order performance penalty to be paid in these circumstances.

The important question that needs to be asked in the end is, ‘what can we do about this?’ In financial organisations, development teams are rarely in a position to dictate terms for their own work. When it comes to attaining flow, seeking some isolation at times may not be a bad thing. Office space permitting, working flexibly on laptops for part of your work may be beneficial, from conference rooms, isolation chambers and break-out areas. DeMarco and Lister suggest – as a last resort, not as a preferred choice – “hiding out” in conference rooms, libraries and cafetarias. When it comes to the support function for the front office, the development team may be wise to not assign single people to support functions, but rather a pool of developers, with clear rules as to how to deal with support requests. Distributing support work over individual developers assigned to front office desks leads to interruptions and distractions from their other work for all of them. Pooling these developers allows for rotation of the support tasks, and more opportunity for flow for those not dealing with these tasks. As for the general lack of awareness of the necessary conditions for successful software development, the best we can do is trying to educate our colleagues and managers on best practices and try to introduce them where we can. As developers, it will be difficult to get support for initiatives affecting big projects that change your working practices too dramatically. Instead, try to focus on smaller projects and trials where perceived risks are lower. When these initiatives are successful, use them to your advantage and as leverage to bigger projects and other preferred working practices. Little by little, you can make your office a more pleasant environment.

References
Beck, K. (1999) Extreme Programming Explained: Embrace Change, Addison-Wesley.

Cockburn, A. (2008) ‘Osmotic Communication’, available from: http://alistair.cockburn.us/Osmotic+communication

Csikszentmihalyi, M. (1997) Creativity: Flow and the Psychology of Discovery and Invention, Harper Perennial.

Csikszentmihalyi, M. (2008) Flow: The Psychology of Optimal Experience, Harper Perennial.

Lister & DeMarco. (1999) Peopleware: Productive Projects and Teams, Dorset House.

Dobson, J.  (2007) ‘The Principle of Locality’, available from: http://jamiedobson.co.uk/blog/the-principle-of-locality/.

Add comment

Name (required)

E-mail (required, but will not display)

Website

Notify me of follow-up comments

Refresh

Send

Cancel