Collective Code Ownership
Collective Code Ownership
We all have our own style of building software. Collective code ownership allows us to create standards that get rid of these silos and allow us to learn from each other.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
Like many artists, I used to sign my work. When I wrote a class or a module, I put my initials in a comment that indicated I was the developer who wrote that code. This was a common practice at virtually everywhere I worked from IBM to small shops that developed financial or banking software. This wasn’t just me, every developer I knew did the same.
Today I code anonymously, and not because I don’t want to get caught in a mistake. It’s because I want to promote collective code ownership.
I believe software should be written in such a way that it conforms to standards and practices and you couldn’t tell by looking at it who actually wrote the code. This is what collective code ownership means, and it’s an important concept in software.
I’m a strong believer in best practices for software developers. I spent my life studying them and I’ve found just a few dozen distinctions can make all the difference in terms of writing a system that’s straightforward to construct and maintain versus ending up with a system that’s a mess.
Developing software in silos, where every developer has their own piece of code to build, which then gets integrated into the system later, is how most software is built. This is a problem. A lot of things can go wrong. We have had to figure a lot out for ourselves as software developers and we all have our own style of building software. I’m not saying one person’s style is better than another’s but different people’s styles can be incompatible when they go to integrate their code. So, for maximum compatibility, we have to arrive at some common standards and practices for software development.
Writing code is an incredibly rich medium of expression that few programmers actually take advantage of. We should be studying great code like we study great literature. But instead, we teach a few programming languages to people, which is equivalent to teaching them a basic vocabulary, and then tell them to go and create great literature. It doesn’t work like that.
Developers don’t learn to write great code in school. In fact, most of the curricula I see, in colleges within the United States at least, are pretty lame. There are a few notable exceptions, but overall Agile, Extreme Programming, design and architecture skills, are not part of undergraduate curricula in software development. So developers have to learn on the job if they’re lucky enough to work under people who know how to build good software.
But the industry has been growing by leaps and bounds. The number of software developers doubles every five years according to Uncle Bob Martin’s estimates, and if that’s true then the average level of experience in the industry is just two and a half years.
We can learn a lot from each other, and this is one of the main benefits of pair programming, mob programming, doing code reviews, doing retrospectives, and all of these are core practices within Extreme Programming.
Published at DZone with permission of David Bernstein , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.