Leadership, transition, and improving our codebases

In the real world there is frequently a gap between an ideal codebase and the codebase we currently have. Fighting codebase entropy certainly involves good coding practice, writing clean code, refactoring code or removing code and testing code, but it also has more abstract organizational and human layers. Managing codebase improvement is actually a process of leadership and transition management. With that in mind, I’m going to skip talking about code specifics and focus on: vision, organizational culture and leadership.

Deep programming knowledge and clean code is only one part of what great developers bring to the table. The best developers are critical practitioners and problem-solvers, aware of the big picture and applying their deep knowledge and craftsmanship to create solutions that will provide value to both the organization they work for and the end user. When solving programming challenges we start by understanding what we are trying to produce, the technical systems and constraints we are working with and we work pragmatically but creatively towards a savvy solution. We also rely significantly on the knowledge, experience and contributions of others, especially within the open source community. Successful transition management also requires many of these same qualities.

Developers rarely work in a vacuum. We work for organizations or clients, with people and on behalf of users all with the hope of delivering a great product that others will use. The implication contained in this reality is that successfully managing the transition towards an “ideal codebase” demands not only clean code but also an understanding of the system we work in and the goal we are trying to achieve.

It starts with vision #

Vision is powerful. Vision is essential to transition management because it paints a picture of what we are trying to achieve with our investment of time and energy. It is a way of re-framing our problem in light of a goal.

During transition, vision provides much needed perspective. It reminds us that the task we are working on is a part of a bigger ecosystem and asks us to lift our heads from the task we are working on in order to think about the whole. It also reminds us not to settle for good enough in our work because we know that if we do, we won’t achieve our vision.

Having a vision during transition is a bit like test driven development: first write the test, and then start working towards it. Once we know what we are working towards, we can plan and agree on the specifics of how we are going to get there adjusting as needed along the way.

Shaping a vision is relatively easy. Shaping a vision that receives the buy-in and support of a team and organization is a more challenging proposition. Even more daunting is cultivating visionary developers. In order to do this, it’s important to have an understanding of the constraints of the environment - both technologically and organizationally.

Understand the Business Needs and Goals #

Regardless of the length of time we’ve been in our work environment, it’s critical to realize that there is a history and a culture in the workplace. It silently and not-so-silently guides working practices; what’s acceptable and what’s not. Steve Jobs famously had an unrelenting obsession to not release a product unless it was “perfect”. In other workplaces, the guiding principle is not perfection but to cut costs. Get it done as fast as possible for as little as possible. Whatever the guiding principle(s), the attitudes influence the work habits and practices of an organization - large or small.

Along side the guiding values, workplace culture is shaped by prior or current investments of time and money. Even with the presence of codebase entropy, the reality is that time, work and energy have been invested into the the current architecture, solutions and workflow systems.

Understanding the culture and history of our workplace is like understanding the languages we code in: it helps us understand the constraints and opportunities we are working with. It also helps give us the tools we need to shape organizational and team vision and connect it with current reality. It provides context for building a business case to convince management of the business value while casting a vision for improved workflows, reduced long term frustrations, a more stable product and ideally providing more opportunities to improve user experience.

Lead well #

With an understanding of where we are, where we’re going and how we want to get there, we have a sort of framework to work within. Continuing movement towards our ideal codebase however, is going to require good leadership. The act of initiating transition demands that we be responsible enough to also lead well.

Adjusting to new practices and mentalities isn’t easy; It takes work. As a result, we need to continuously cast vision, communicate clearly, lead by example, hold people accountable and ensure that we give them time to adjust to the changes. If we know that we’re making changes that will impact working methods or workflow, it’s important to facilitate a transition process and give people time to adjust. Otherwise, they will be frustrated and so will you when adoption doesn’t happen as quickly and flawlessly as you’d like.

Conclusion #

Leading transition and closing the gap between the present moment and an ideal codebase full of beautifully functioning clean code that is scalable is no easy task. It is a rich journey that requires us to be both great developers and great leaders. The results for us, our organizations and yes, ultimately, our users are worth it.

Further resources:

Of course this is a topic that demands far more than a blog post to do it justice. Here are a couple books to provide more food for thought along the way.

• Primal leadership by Daniel Goleman
• Leading Change by John Kotter