Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage Antipatterns Content on InfoQ

  • 3 Pillars Of Executive Support For Agile Adoption

    An executives job is not over once they've justified agile to their teams and paid for training. To make a transition successful, its required this executive provide sustained support. Esther Derby takes a moment to describe what she believes to be the 3 most important aspects of this ongoing support.

  • How to Ensure Early Death of a Distributed Agile Project?

    Challenges of Agile adoption and execution get amplified when working in a distributed mode. Distributed Agile brings its own share of challenges in terms of geographical separation, varied timezone, cultural differences etc. Killing a distributed Agile project is not very difficult.

  • Careful With Your Coverage Metrics

    Christian Gruber takes some time to clarify the TDD stance on using code coverage metrics. He discusses what code coverage metrics do and don't tell you, how TDD fits into the picture, and how one might be best advised to use their code coverage metrics.

  • MS Experience Yields Distributed Agile "Dos and Don'ts"

    Ade Miller has published a paper on distributed agile development, highlighting the challenges of trying to do distributed agile development, along with recommendations for addressing these challenges based primarily on the experiences of teams within the Patterns and Practices group at Microsoft.

  • What Makes Good REST?

    Roy Fielding casts an eye at the SocialSite REST API and finds it is less than a perfect REST citizen.

  • InfoQ Book Review: Agile Adoption Patterns

    Ryan Cooper picked up Agile Adoption Patterns: A Roadmap to Organizational Success by InfoQ's own Amr Elssamadisy and gives this book a positive: This book belongs on the bookshelf on anyone who is interested in helping a traditional software organization make an effective transition to a more agile way of working.

  • Debate: Should Architecture Rewrite be Avoided?

    As it gets more and more difficult to adapt software to new demands, the temptation to rebuild it in order to update the architecture grows stronger. For this risky undertaking it is essential to choose the right strategy. Several authors provide insights into advantages and disadvantages of different possible options in terms of cost, technical complexity and potential commercial risk.

  • Leading Troubled Projects: Secure Your Own Oxygen Mask First

    Fiona Charles' recent StickyMinds article looked at leading troubled projects. Stressing that "this is not the time for rigid process over progress," she provided valuable insights to help a team turn around a troubled project. She also reminded us to watch out for improvement: if there is none it could be a Death March, and time to leave.

  • TDD: Essential Skill or Architectural Landmine?

    At JAOO '07 Bob Martin asserted: "it is irresponsible for a developer to ship a line of code he has not executed in a unit test." In this InfoQ video, Martin debated with another well respected software thought leader, Jim Coplien, on this and other topics, including Design by Contract vs. TDD and how much up-front architecture is needed to keep a system consistent with the business domain model.

  • Decisions driven by productivity concerns: Reasons, implications and limitations

    Often the necessity to rapidly adapt software projects to new clients’ needs results in adopting approaches focused on productivity. Reasons, implications and limitations of this were recently discussed in the blog sphere.

  • Can architecture create a gap between developers and software they build?

    Many software project management and architecture approaches tend to parcel out work on a project in a way to create hierarchical layers. This helps simplify both developers’ work and management. However, the underlying information shielding among layers can potentially create a gap between developers and the software they are building, if their tasks are totally taken out of functional context.

  • Preserving flexibility while using Active Record pattern

    Bob Martin believes that Active Record pattern that maps data structures to objects may be a source of confusion. Even though it appears to be an object, it actually is a data structure, vulnerable to the addition of new types. To preserve the flexibility, Bob Martin suggests separating Active Record from the application, so that the latter can be designed and structured solely around objects.

  • Holding a Program in Your Head

    Your code: is it that stuff you store in version control or, as Paul Graham argues, "... your understanding of the problem you're exploring"? Graham has written an essay offering eight suggestions for developers trying to understand the code on which they're working - some of which seem to contradict the advice of the agilists.

  • Why do Agile Adoptions Fail?

    Although agilists focus much of their energy on helping their agile projects succeed, it is helpful to periodically stop and consider what causes some agile projects and agile adoptions to fail. Armed with this knowledge, perhaps one can avoid these same pitfalls.

  • Resolutions: Integrity of Code and Conduct

    At the start of each New Year, some of us stop to look backward, and actively resolve to move forward wiser than before. Scott Ambler, Liz Barnett and Kirk Knoernschild have shared with us their recommendations for working smarter in 2007, including: take a hard look at at your business objectives; equip your teams properly to maximize agility; and above all - behave yourselves!