The sorrow of code quality, with agility!
Sundar Rajan Muthuraj, Clean Coder - Full Stack
Principal Engineer | Clean Architecture | Mentor
In the event of trying to deliver software faster, it's a worrying phenomena that the industry is churning a lot of non-maintainable code.
- How many of the coders in the industry today have been sold towards the thought process of - "Make it work and make it clean and make it faster"?
- Although the coders often read more code (read and read and read the code all the time) than they write, with an estimated read:write ratio being 10:1, how many of the agile software development teams coach - the first step towards increasing the productivity of developers is to enable the team to write "readable code"?
- With the concept of "dedicated QA" slowly being diluted, is the organization vigilant about making the developers more serious & matured about Unit Testing & Automated functional testing?
- Why is TDD seen as a tougher affair, when Agile is seen as a de facto?
- What is the use of Agile, when it can turn a good coder into a bad coder due to the fact that it's impractical to write "clean code" within an iteration? (Remember: make it work, make it clean and make it fast cycle?). Well, engineers end up thinking optimistically that - OK, let me overlap the cycle of - make it clean, across iterations. But oh Boy - the sad truth is - Almost every iteration is going to be similar, if not all! And the code rot continues and continues! :(
And with many more lingering worries in mind... I want to lay down a couple of thoughts:
- More and more senior individual contributors (Technical Leaders, Principal Engineers) are the primary people who can fix/streamline these issues. But how? - Take some time out to understand that the real meaning of being "agile" is embracing a technical excellence of going faster "only by" going clean, than magically being productive by following bookish "scrum".
- It's the management responsibility (engineering, of course) to make sure that the least experienced engineer in the team understands the big picture (business angle) of the project, and the most experienced engineer in the team (may be so called "architect") also writes code during the iterations.
Happy coding, Happy engineering!