Modern software development, whether we are talking about the more traditional waterfall model or more modern agile methods breaks down requirements into units. The name and size of the unit varies, but usually they boil down into tasks. Project management is usually concerned with how we are progressing in delivering the tasks. This has been accepted as the way to develop software professionally.
There is a stark difference between these traditional approaches to developing software and what software developers do when coding for enjoyment. Coding for enjoyment is vastly more productive than completing tasks off a gantt chart or kanban board. This article is an examination of what separates 'professional' coding and coding for enjoyment, and how we might capture some of the benefits of coding for enjoyment.
Ownership
Ownership is an emotional state where you are invested in the project in it's own right. You feel that you own it in a tangible way and that you have the authority to do what you want with it. In fact when you are coding for enjoyment you hold all the power as you are your own customer. You can make the software be whatever you want it to be. There is no communication friction between customer and developer because they are one and the same person.
The best way to motivate developers is not through extrinsic motivations like bonuses, free soda, large desks and unique environments, but rather through intrinsic motivations such as pride and a feeling of ownership in the code they write. The best way to destroy any sense of ownership is to give developers tightly constrained tasks that involve no judgement or ownership in their implementation. The point of user stories was in part to ensure that the requirements are supplied to developers in a way that has maximum latitude for implementation. However, even with Agile I have seen ownership undermined when stories are too granular.
My early software development experience was one where I had no choice but to own the project. Failing to meet customers needs efficiently would result in not getting paid. By comparison many young developers today are treated as machine parts, coding small parts of implementations and given little real responsibility or ownership in what they do. It would therefore be little surprise that young developers would see the industry in a negative light. By undermining ownership we undermine creativity, adaptability and pride in the product.
Empathy
There is no English word to describe what I'm going to talk about next, but 'empathy' is close. Rather than simply reading tickets and implementing them exactly according to the description we should be aiming to gain a deep understanding of the problem to be solved. Often a set of requirements or even tasks are the result of preconceived notions about how something should be done.
Years ago I performed a systems analysis of a reconciliation process so that we might automate the system for them with software. They had been running a time intensive manual reconciliation process. After several interviews with all the staff involved I understood the problem they were trying to solve and as a result was able to recommend a new manual process that would not involve writing new software but rather eliminate unnecessary work to achieve the same result.
On more than one occasion I have been involved in projects in which I have been treated as a machine part, following small tasks, only to find later that there was a simple, elegant and far less costly solution if only the customer had bothered to communicate the high level problem earlier. This is not about seniority; do not assume that young inexperienced developers can't have good ideas or new perspectives. Often they are able to provide a fresh perspective unconstrained by preconceived ideas.
All too often we try to separate the business analysis and architecture into separate functions. In doing this we are creating distance between the customer with the problem and the person building the solution. This is not to say there is no role for a business analyst, only that they must work closely with developers and ensure that they are more than ticket mills. They need to be able to communicate the mission of the software and to give developers a deep understanding of what the problem looks like.
Architecture in my view is something all developers need to appreciate. Issues such as performance, scalability, security, high availability and usability are all aspects which are not usually explicit requirements in a project. But they will almost always be implicit requirements. Just as quality is the responsibility of all developers so are the architectural principles. Architecture is not separate from the system, but rather its foundations.
The Architect as a role exists to ensure that developers are aligned and engaged with architectural concerns. They are there to collaborate with developers to ensure that systems are built that address the implicit requirements. This means working with developers at the coalface rather than the all too common anti-pattern of the 'helicopter' architect who drops a design onto developers from above with little discussion only to fly away into the sunset long before implementation is complete, or as often the case, started. This is catastrophic in two ways. The first is that the connections between the customer and the developer are broken. Without these links it is impossible for the developer to establish a deeper understanding of the needs of the customer . If all you have is the design you have no way to determine if it is actually meeting the needs of the customer. Second, it undermines developer ownership. By dropping designs onto developers they lose any sense of investment in the success of the implementation because they have no agency to alter the implementation. They become hired guns disinterested in the outcome.
Efficiency
Every person you put between the customer and the developer adds friction to communication. The less direct communication there is the less empathy and understanding is established. Sometimes you need a customer proxy like a product owner because there are many customers and many competing priorities. But whether you have a real customer or a proxy they must be available and engaged in order for the empathy building process to work.
By building empathy developers gain an intuition such that they can put themselves into the heads of the customer. This has a two fold benefit. First they can often answer questions for themselves without talking to the customer. If they have a deep understanding they can make calls on the approach to take in the implementation without incessant micro questions, such as "where should this field go?"
Second, they have the freedom and ownership to be more creative and innovative in the delivery and implementation, rather than simply following a precise set of plans.
To use an analogy is it the difference between being given a precise set of driving instructions and being given a map with the destination marked. In the case of driving instructions if there is any deviation they become invalid and you don't arrive. With driving instructions they may not cater for new information, such as a road being closed or a new motorway that will allow you to reach the destination earlier. Driving instructions are brittle and do not adapt. Maps however, even if imperfect, are better because they permit the driver a certain degree of latitude in how a driver navigates to the destination.
And so, the approach of communicating in terms of tickets or tasks is like the driving instructions; giving the driver little latitude and being inflexible. The map alternative on the other hand gives the developer a deep understanding of the problem to be solved and more freedom to be creative thus will ultimately deliver better solutions faster.
In The Zone
Clearly communication is vital for the success of a project. However this does not necessarily mean continuous interruptions and interaction. Part of the importance of gaining empathy is so that the developer can operate without excessive communication, able to answer their own questions when issues come up based on that deeper understanding of what the customer is trying to accomplish.
Coding is a complex task which requires the developer to hold many aspect in their head at the same time. Developers that are 'in the zone' do not actually follow clearly segregated mini tasks. In my experience this kind of hyper segregation only serves to break the spell, to take you out of the zone.
The zone is a period of uninterrupted focus. Unlike well organised task lists I personally find operating when in the zone is far more fluid. Often spending an hour or two working out how certain things can be abstracted can save potentially hundreds of hours downstream in the detailed implementation.
While being in the zone involves having focus it is also rather disorganized. It s like freeing the creative dreaming side of your brain. It allows you to achieve more than the more structured analytical approach.
When the tasks and their order is enforced this mode of thought becomes impossible as you become more like a robot simply following instructions. By having a higher level story you can at the same time focus on that outcome which utilizing your creative side. It would be interesting to examine this aspect in a more systematic way.
Conclusion
We will never be able to achieve the same performance level as that achieved when coding for enjoyment when coding to meet the needs of others, but there are things we can learn about ownership, empathy and deep understanding of customer problems which can help us engage the creative and innovative engines of developers.
The differences between the best and worst developers is less to do with individual excellence and more to do with the approach developers take to how they work, which in turn is influenced by the culture within organisations.
Top comments (0)