2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- September 13, 2017 ( 2 comments )
- Bits and Pieces
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 get 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.
{2 Comments }
Previous Post: « Forget About Velocity
Next Post: Pairing and Collective Code Ownership »
I was writing an article about collective code ownership and found your article via Google. Thank you for your insight and I have found it very inspiring, especially about the fast increasing number of developers with disproportionate experience of developers.
Thank you so much. It’s always nice to get positive feedback. I’m glad you found value in my post.