March 26, 2010 by huionn
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
This statements was made in 2001. Although agile methodology is growing in popularity, I think not many people come across this manifesto.
I think many IT companies want to apply agile methodology, but in fact using waterfall model in disguise. One of the syndromes is that manager is interested in comprehensive documentation because working software is “incomprehensible”.
Over the years of working, I am always self-learning. Therefore, I expect others are doing the same and I have never voluntarily provided any kind of training to coworkers. Focusing on my own improvement in technical skills, I have failed to see the big picture. Software development requires teamwork.
I can write clean code by applying SOLID principles:
Single Responsibility Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
(Those are very pragmatic principles but may not be intuitive. It is until last few months that I finally comprehend the importance of LSP and ISP although I understand SRP, OCP and DIP years ago).
Recently I was reading codes written by colleagues. All codes are working codes, but maintainability are overlooked or neglected. There are a lot of code smells (Refactoring by Martin Fowler).
There are plenty of copying properties from one object to another in different places – this is brittle code. Adding new properties required developer to scan through the class to add copying the property.
Long class – the class is doing a lot of unrelated task. It violate SRP.
Duplicate code – 2 methods are doing similar thing but slightly different in codes.
Long method – it violate high cohesion principle.
Due to my personality, as a team lead, I am very lenient to coding standard compliance. Once in a while, I do code review. If I find anything that is not following the coding convention / standard but is still working, I will just give recommendation and close one eye. I have never asked them to change the code accordingly. I thought this kind of freedom to developers is favorable as they can code in any way they like. I was wrong…
Different developers have different coding styles. Some are good whereas some are bad. Unless the bad coding styles are explicitly pinpointed during code review, the developers are always doing it in the same way. This is true, because I will be also the same unless I find the better solution by reading others’ codes.
By three methods we may learn wisdom: First by reflection, which is the noblest; second by imitation, which is the easiest; and third, by experience, which is the bitterest.
—Confucius, Analects, 16.9
Self-reflection is noblest but also the hardest.
As I found out now, various coding styles (solving same problem in different ways) compromise consistency of software system and hence can affect conceptual integrity of software architecture. It significantly increases software complexity as maintainers need to understand every ways of coding.
I should not repeat the same mistake again. When I work in the new company, I will become "benevolent dictator"!