A common misconception is that a software developer works in isolation, only rising from their cubicle a few times a day for a zombie-like shuffle to the vending machine. In reality, software development is a collaborative and creative occupation. While the act of sitting at a desk and writing code is an important aspect of creating software, it’s not the sole focus of the average day of a software developer. A developer spends more time reading code than writing code, formulating a plan on how to work with oftentimes very complex software originally written by someone else. Planning, designing and brainstorming should be an extremely collaborative process, with team members working closely together to support the art of building software that no single developer could ever create on their own. By the time a developer begins to write a line of code the most difficult part of software development is already done. The technical discussions at QCon were fantastic, but just as intriguing were the discussions about design, people and how to build an effective product delivery team.

This is part two of our Lessons from QCon series – Domain Driven Design and people matter.

Eric Evans (Domain Driven Design): It’s all about values
We often talk about data and values, but it helps to think about a quote from Douglas Coupland in Microserfs.

“We’ve reached a critical mass point where the amount of memory we have externalized in books and databases (to name but a few sources) now eclipses the amount of memory contained within our collective biological bodies.”

This is seriously intense stuff. Within a few short generations we’ve managed to digitize most of our collective knowledge. We’ve sure come a long way from drawing on cave walls. This is why it’s so important to think about how we model, store, and work with this vast amount of digitized information and how our software interacts with it. After all, most modern software applications are friendly interfaces for working with vast stores of data.

As software becomes more central to our daily lives it becomes even more important that we take the right approach to designing software, especially complex software for complex business domains. One popular technique is called Domain Driven Design and was discussed by Eric Evans, author of Domain-Driven Design: Tackling Complexity in the Heart of Software.

A lofty approach to software design is to try and impose order over an entire system by creating a global (or enterprise) domain model. Or as Eric Evans put it…

“One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them”

This approach is considered sophisticated design, a noble objective that usually adds unnecessary complexity to a software project. The issue with sophisticated design is that over time software devolves into a big ball of mud. Patches, fixes, changes, modifications; these all take their toll on sophisticated design. Often times the end result is a high-cost legacy application that is too complex and expensive to maintain so it needs to be rewritten. And often times the rewrite devolves into another big ball of mud, with the vicious write/rewrite cycle continuing.

Rather than try to impose a singular true model, Eric suggests taking the modest approach of modelling data in the same context that it is used. It’s a simple concept, but by defining sensible boundaries between different components of a system, each component can be maintained and optimized individually. This may sound familiar, because it’s exactly how the team at Twitter approaches design.

VersionOne and Menlo: People matter
A recent pattern in software development is engineer-led teams supported by people in diverse disciplines such as anthropology. Expectations of an application are much higher today than a few decades ago as software is now such an integral part of people’s daily lives. It’s not good enough to build software the right way if you’re not building the right software. It’s widely recognized that a deep understanding of people is fundamental to building amazing software. Facebook and Twitter achieved initial success not simply because of a technological advantage, but rather because they slowly began to fundamentally change the way people communicate with each other.

Top companies gain not only a deep understanding of their users, but also their own teams who build their software. David Laribee of VersionOne gave a fantastic talk about how to build a top-tier product delivery team. It all boils down to culture, and David gave some excellent advice on how to shape the culture within a team. One of the most interesting practices at VersionOne is the use of DISC profiles. DISC is a behavioural model used to examine the behaviour of individuals in their environment. It focuses on the styles and preferences of such behaviour and makes it easier to learn about others and how to best collaborate with them. Each member of the VersionOne team completes a DISC profile and uploads it to their company wiki. When working with a new teammate, it’s easy to check out their DISC profile and gain a better understanding of their personality and communication style in order to effectively collaborate with them.

It’s very important for members of the VersionOne team to gain a deep understanding of fellow team members, because like most companies at QCon, VersionOne practices pair programming. Pairing (or pair programming) is a love it or hate it technique that has gained traction in the software development community. By always pairing team members, the work they produce together is constantly under review, constantly optimized, and the knowledge gained is spread rapidly around the team as pairs change. Richard Sheridan of Menlo describes pair programming as “the most effective management tool he’s ever encountered”. A common reaction to the idea of pair programming is scepticism as the idea of two people working on a single task seems wasteful. The belief that the cost of work will double because two people are working on a task is untrue, because pair programming involves two people working, not one person working and one person watching. Organizations that adopt pair programming generally notice a reduction in cost due to the higher quality of finished work. The biggest challenge of pair programming is cultural as many teams are made up of people who are more comfortable working individually. This brings us to our next topic.

What if you want to change practices, but it doesn’t fit with team culture? David Laribee believes that culture is best shaped during the hiring process, and he often “hires ringers”. Rather than compromise on process to fit within existing culture, he believes in defining culture and shaping the team around that definition. The belief is that successful companies don’t simply define culture as a static milestone, but rather evaluate their culture on an ongoing basis. VersionOne takes this technique one step further and evaluates their culture during team retrospectives. Pairing and culture have a direct relationship on one another, as it’s easier to foster a culture when teams collaborate constantly. Both companies go one step further and design their physical office space to support pairing by creating workstations that are suitable for two people rather than one, referred to as “pairing stations”. The idea behind pairing stations is that physical space is critically important to the culture of a team, and by moving people around their physical space constantly, it avoids stagnation and cliques, while fostering teamwork and spreading knowledge throughout the team.

Summary
Top technology companies not only focus on software, but they focus on people. They optimize for happiness, and as Richard Sheridan puts it, they understand “the business value of joy.” Joyful teams produce fantastic software, and thanks to a new breed of hyper-collaborative and creative technology companies the dark days of programming in isolation are slowly ending. It’s a fantastic time to be a software developer, and QCon was a fantastic opportunity to learn how some of the most successful companies in the world approach this wonderful craft.

Tags: David Laribee, Domain-Driven Design, Eric Evans, Menlo, QCon, VersionOne

1 comment