BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Antipatterns Content on InfoQ

  • 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!

  • Presentation: Ken Schwaber on Code Quality as a Corporate Asset

    Scrum co-creator Ken Schwaber spoke at Agile2006 on code quality as a corporate asset. InfoQ presents video of his talk, The Canary in the Coalmine. Schwaber discussed how a degrading core codebase paralyses a team and negates any Agility gained through process improvement. He proposed strategies for management to identify, track and stop this downward spiral.

  • InfoQ Article: Do Agile Practices Make it an Agile Project?

    As adoption of Agile methodologies grows, challenges abound, including the possibility of dilution as teams copy practices rather than growing them, implementing them without understanding. InfoQ's own Deb Hartmann gives us a frank discussion about how failure to teach the basics puts much at risk: the integrity and engagement of team members, and the trust of their customers.

  • Fowler: "Agile Imposition is a Very Red Flag"

    Martin Fowler, one of the original creators of the Agile Manifesto in 2001, reflected last week on reports of Agile process being imposed on teams from the outside. He states his reaction succinctly: "Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception."

  • Practitioners Adapt Agile to Local Constraints

    Some people think they can only be Agile with small, co-located teams and full management support, but most teams aren't that lucky. So, should they should give up on Agile techniques? Scott Ambler's answer is a resounding "No!" His Dr. Dobbs article "Imperfectly Agile: You Too Can Be Agile!" outlines how Agilists overcome common challenges that others use as excuses for not being Agile.

  • No Bug Database?

    James Shore, a recognized speaker and writer in the Agile space, has had a crazy idea: Get rid of your bug database. He's not advocating that teams ignore problems; but bug databases are often so packed with questions, feature requests, and defects that there's little hope of their all being resolved. Shore and some others in Extreme Programming circles think there's a better way.

BT