Agile Anti-Patterns
I believe that Agile is a great tool to help development teams achieve more, improve, and reach their next level in effectiveness, productivity, or creativity. However, like any tool, it can be misused or misapplied. You can shoot yourself in the foot if you are not applying a certain level of discipline or hygiene.
Mike Griffiths posted a short and sweet article on this subject that he entitled Agile anti-patterns. He classifies those anti-patterns as follow:
- Agile as a silver bullet
- Agile as an excuse for no discipline
- Agile without explanation
- Shallow Feedback
Frequently Forgotten Fundamental Facts about Software Engineering
In this article, Robert L. Glass, list principles, facts related to software engineering. The list is organized onto the following categories:
- Complexity
- People
- Tools and Techniques
- Quality
- Reliability
- Efficiency
- Maintenance
- Requirements and design
- Reviews and inspections
- Reuse
- Estimation
- Research
I encourage you to read this article regardless if you are new to the field of software engineering or a long timer. Sometimes it is nice to be reminded of the "law of physics' regimenting our discipline.
[via IEEE]
Skepticism in Software Development
I just read an article from Jason Gorman, from Parlez|UML, on skepticism in software development. He explains that a lot of preconceived theories about software development abound but few of those theories have been thoroughly investigated and therefore, it is difficult to know if they bring value to the engineering process or not. For example, Jason mentions refactoring that claims to make changes easier without supporting research.
In my understanding, this leads to more academic research on those theories to validate them and also to explore their practical boundaries and limits. I believe that this is a perfectly valid, and necessary approach.
However, in parallel to this academic approach, I would have a tendency to take a more pragmatic route. If a concept like refactoring comes to my attention, I would try it out in my environment, see if it has value to my organization and decide, after retrospective, to continue using the method or not. Also, you can not detach the software engineering method or principle from the human component. The method, under properly applied leadership, has to be accepted and embraced by the programmers, testers, or UX designers that would use it. Therefore, the development team, including its lead, decides, if a particular theory helps bring more value to customers.
[via Parlez|UML]