Courage and Accountability

Leena
Continuous Delivery
3 min readJun 18, 2018

Bottom line: code quality is the responsibility of the people who actually write the code (otherwise known as Programmers).

As programmer, you own the problem, and you own the solution. There’s no need to fret or be ashamed of the past. Instead, stand proud and use your power to do something about it — make a loud decision to Stop Writing Crappy Code. That will start a chain of events and Good Stuff will likely follow in the long term. It’s hard and it takes courage, but I don’t know any other way to solve technical debt.

Good luck!

/Henrik —From the post Solution to Technical debt

What stands out in the above summary is courage. What courage has to do with technical debt? And courage for what?

Courage is one of the values of Extreme Programming (XP). Jeff Langr and Tim Ottinger in the book Agile in a Flash explains courage as follows:

http://agileinaflash.blogspot.com/2009/02/courage.html

And surprisingly, the above is a potential solution to Technical Debt — not easy though 😄. And for this to happen, the team should take collective ownership. Collective code ownership — another practice by XP — is defined as follows:

http://agileinaflash.blogspot.com/2009/02/collective-code-ownership.html

James Shore in the book — The Art of Agile Development — explains Collective Code Ownership as:

With collective code ownership, everyone shares responsibility for code quality. Anyone can make necessary changes anywhere, and everyone is expected to fix problems they find. To make it work, let go of your ego. Take as much pride in the team’s code as in your own code.

Yes, the key here is ego. Letting go of the unnecessary pride in “my code”, and the lack of pride in “other’s code”. It is about being humble and approaching programming with humility.

Closing note: I took some courage and accountability to refactor code [written by someone else]. I deleted the unused code too [along with the tests]. I felt excellent when the code looked cleaner than when I approached it. And the thoughts written above came in while I was analysing my refactoring.

I also screwed up the production by deleting an API which I thought was not required but was in use 😢. The recovery time was longer because we were not using the production metrics rightly. Lessons learned (again), need to have good feedback systems to alert us when specific user action metrics go down blow a bar.

But it was not as bad as the Internet went down when 11 lines of code got deleted. Of course, mine was not intentional 😄.

--

--

Leena
Continuous Delivery

Co-founder/CTO @ PracticeNow, Bangalore, India. A strong believer of lean principles, an evangelist and practitioner of Continuous delivery