“Can I change this code?” sounds like a normal question, but in my opinion it expresses a problem in agile development that needs addressing.
Foremost: This is a very good question, because it shows a noble intent: Make code you found better. Following the boyscout rule “always leave the campground cleaner than you found it” is among the best practices for coding. But the question indicates that there is something in the way of doing it. In Scrum you call this an impediment which calls for resolution, but also non-Scrum projects should take care of it. Also it should be said that solving this on a case by case basis doesn’t work. Effective development is only possible when this question is never asked again.
Here some reasons I found most common for asking the question and possible solutions:
- The code in question is not accessible, or politically tabu ⇒ Convince your teams that common code ownership brings benefit for everybody and is not about undermining special assignments of teams. Most developers will be very careful when touching others code, so the risk is neglectable.
- The code refactoring will break existing API ⇒ For many projects this problem is not as big as usually perceived. Usually the code is used internally only, and perhaps the new API will be much more pleasant to use. Even when this API is used externally, there is nothing wrong with changing API in a controlled manner.
- The developer is uncertain of her skills ⇒ Our industry demands for continuous learning and actually many developers like working on stuff that’s new for them. Its okay to feel unsure, but new ideas could make old code better. Let the developer pair program with the original author or one of the more experienced folks on the team. If everything fails there should be tests…
- Nonexistent tests make the change risky ⇒ Invest time in writing tests that check the current code behavior. If the change is intentionally changeing behavior, find out if thats okay, by talking to an architect, or by checking who uses the code you want to change.
- The actual usage of the code is unknown ⇒ try to get a big (architecture) picture and as much as code from this or dependent projects as possible. Create a big refactoring setup for developers to use in case of this kind of code changes. IDEs can find many possible usages of code and CI servers can also run on refactoring branches.
- There is no backup ⇒ Still running without version control? Do your homework and get one.
Changing code is good, because we all want to make it better or nicer. It helps keeping solutions clean and simple. If you are not going to change the cause (a bug, design flaw or whatever), people start to introduce workarounds, with is not nice, not clean, not simple and just a waste of bytes.
My call to developers is:
“Don’t be afraid of changing other peoples code with good intend.”
My call to project managers and SCRUM master is:
“Make changing others code a pleasant experience”
To answer the question in this postings title with a prevalent quote:
“Yes, you can!“
Was this post helpful?
More articles
fromFabian Lange
26.3.2015 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Fabian Lange
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.