00:00:09.280
My name is Michael Feathers. I've been in the industry for quite some time and have worked with Optiva, which was recently acquired by Groupon. We're calling it 'Grouptiva' right now. The keynote today is centered on a topic I refer to as 'code blindness.' I believe this is an affliction affecting our industry.
00:00:21.439
It's a bit strange, and I often wonder if others recognize this problem as I do. Today, I want to discuss it and explore ways we can move past this issue. How many people here have bosses that actually look at their code? How many have people two levels above them in the organization who review their code, which is kind of rare, right?
00:00:38.800
Given that many of you are part of startups, does that sound about right? More often than not, we work in consulting, developing web applications for larger companies. What's striking to me is the persistent disconnection between software developers and business. This gap has existed for ages, and despite various attempts to bridge it, we continue to deal with its effects daily. It's an issue we truly need to address.
00:01:11.200
Getting into this topic personally has been a unique experience for me. I got involved in the industry in the 90s at a biomedical company. It was eye-opening to see how software development was viewed there. In that company, people developed medical instrumentation and had to get all of the science right first.
00:01:33.759
They had multi-year development cycles but, when it came time to incorporate software, we were at the tail end of the process. After all the hardware and chemistry was developed, they'd turn to us and ask if we were done with the software. It was challenging to explain our role, as it felt as if we were an afterthought at a hardware-focused company.
00:02:01.680
As a consultant, I noticed this institutionalized hardware culture in other areas as well. During my time working in telecom, I encountered a vast software development organization where the higher-ups did not fully comprehend software development. This lack of understanding led to some peculiar decisions. This disconnect is not just an isolated incident within a particular industry segment; I've seen similar issues in banks and insurance companies.
00:02:53.120
In some organizations, they regarded software as a secondary need and would delegate it to a separate team. They would hire developers and expect them to produce quality software while trying to manage their costs. This disconnect appears to be a formula for failure. It highlights the issue: there are people who need software but don't grasp what effective software development entails.
00:04:05.680
Agile software development has existed for about ten years now. I first engaged with Extreme Programming in the early 2000s, followed by Scrum. The original intent behind these methodologies was to foster conversations between business and development, aligning them on mutual goals. Agile emerged as a response to dysfunctional situations where developers could not deliver satisfactory software or communicate properly with their customers.
00:05:39.600
The founders of Agile methodologies established processes to facilitate better collaboration between business and developers. Although I see evidence of these practices being widely adopted, I believe we have not yet delved deeply enough into this issue. It’s essential for organizations to make informed decisions for the future. Communication is key; we need to ensure that information flows effectively across the organization.
00:06:07.520
When we discuss communication, especially within Agile, we typically refer to the product backlog and the estimation process for sprints. However, this is a narrow form of communication and can lead to challenges. Many of us have probably worked with a codebase that began to deteriorate over time despite our best efforts. There's a contradiction here: Agile promised to keep our codebases healthy, yet we still encounter deteriorating conditions.
00:07:20.120
Organizations may initially understand software development's complexity, but without a culture that appreciates the need for sustainable development, it's easy to cut corners. When tasks are rushed, the quality suffers, leading to a downward spiral. Multiplying concerns arise from the tension between the market demands for new features and the realities of a deteriorating codebase.
00:09:03.519
One of the key gaps we face is a lack of visibility into the code across the organization. Non-technical stakeholders need to understand how their decisions impact the software's value. I've been accused of wanting everyone to be technical. From my background, I realize that successful organizations tend to have technical knowledge permeating all levels.
00:09:44.640
People recognize the importance of software so that when trade-offs are made, decisions align well with the code's prevailing condition. How many of you work in organizations that share that knowledge? A couple… I sense a need to dig deeper into this.
00:10:20.160
Regarding code blindness, I've observed several levels of ignorance. The first is total ignorance, where management lacks an understanding of software development's nuances. I've visited companies where after certain managerial levels, decisions about staffing and project priorities prevailed over genuine software considerations.
00:11:15.680
In these organizations, it's almost absurd that there isn't a comprehensive view of the underlying code asset they're working with, leading to poor decisions that result in slowdowns and inefficiencies. The deeper one goes beyond that ignorance, organizations often try to implement metrics to gauge progress. While metrics can provide some level of control, they come with numerous pitfalls.
00:12:08.880
One common trap is relying too heavily on metrics, which can lead to unintended consequences. I've seen organizations become fixated on increasing test coverage scores or ensuring no methods exceed specific line counts, ultimately diluting the quality of the work.
00:12:57.760
When teams focus solely on metrics, they may produce tests that lack real value. Developers will find ways to game the metrics, resulting in compromised integrity and questionable outputs. Metrics indeed have their place, yet it’s crucial to view them within context.
00:14:03.040
Progressing beyond metrics, I advocate qualitatively assessing software's structure. Using qualitative assessments with visual tools can illustrate the health of our software and highlight issues without overwhelming technical details.
00:15:28.000
Imagine showing a visual representation of a code class, detailing its methods and attributes. Such depictions could facilitate discussions with developers and non-technical stakeholders, providing clarity on how code quality aligns with business goals and why certain estimates may take longer.
00:17:06.880
Furthermore, I suggest embracing the life cycle of software. Like living organisms, code requires nurturing and attention. Acknowledging that sometimes, drastic measures, like effectively 'killing' outdated code, may be necessary to allow for a healthier software environment.
00:18:20.800
We should rethink how we approach software and consider its life cycle genuinely. Organizations perform best when they consider the code's value and allow for gradual improvements and determinations on code replacement versus mere refactoring.
00:19:43.440
Software is viewed as a living entity that requires proactive management. This means recognizing when portions of the codebase may be hindering progress, ensuring that we act strategically rather than political battles over resources.
00:20:26.000
In this context, I’d like to highlight Conway’s Law, which states that the structure of software mirrors the communication structure of the organization producing it. This awareness is key to aligning development efforts and bridging the gap between teams.
00:21:39.680
We must also consider the concept of technical debt, originally presented by Ward Cunningham. While the notion indicates that teams may incur temporary 'debt' for short-term results, it’s essential to manage it to avoid long-term complications.
00:22:51.200
The danger arises when teams ignore accumulating debt. We should aim to reflect on our codebases, acknowledging that some entities may need to be 'killed' off when their existence no longer serves the overall objective.
00:24:42.000
People often neglect the need to eliminate unnecessary features and code segments. A culture wherein developers routinely evaluate the code, identify unneeded segments and take decisive action can result in long-term health for projects and companies.
00:26:11.680
To conclude, I encourage you to embrace these key ideas: prioritize awareness of early signs of software issues, reassess the true economic value of software strategically, and embrace a culture of thoughtful replacement of code elements when necessary.
00:28:24.800
My goal was to share thoughts that stimulate a deeper understanding of addressing code blindness within our sector. Thank you for listening.
00:29:31.120
If there are any questions or comments, I am happy to discuss.
00:30:06.399
Thank you all for your time and insights.