How to reduce the life of a software defect?

While building software for large projects with zero defects is virtually impossible, the quality of the software can be determined by the lifetime of a defect – the time when a defect is identified, fixed and released. A defect in a well-isolated module can be easily identified, root-cause analyzed and fixed in a short amount of time than a highly cohesive system.

In addition, adopting an agile development methodology helps  reducing the lifetime of a defect drastically. This is possible by releasing well-tested software in short bursts or iterations and delivering higher quality software compared to other development methodologies.

In an agile project, tests are written before or concurrently while producing the code. Therefore, all code that is delivered for testing is tested code. In most agile projects there are four primary layers of testing:

[box]

  • Unit testing, also called development testing.
  • Acceptance testing, also called functional testing.
  • Component testing.
  • System and performance testing – integration testing and testing for non-functional requirements.

[/box]

In agile methodology, the primary goal is to test all these layers during the course of iteration.

Continue reading “How to reduce the life of a software defect?”

What makes a good Solutions Architect agile?

An agile Solutions Architect is someone who values:

  • Individuals and interactions over processes and tools.
  • Building the software collaboratively with the development team over producing comprehensive documentation.
  • Designing a flexible solution anticipating future requirement changes over current requirements
  • Tapering down the flexible solution (described above) to meet time and budget over a solution that is build like a glove from ground up to meet the current requirements, time and budget.

While there is value in the items on the right, a pragmatic solution architect values the items on the left even more.

In addition, to be agile, a Solutions Architect should:

  • Keep the architecture documentation alive by constantly updating it and keeping it current to reflect the current state of the architecture.
  • Welcome requirements change late in the development cycle to support the development of a product in a constantly changing environment.
  • At regular intervals reflect on how to make the architecture more effective and fine tune it to adjust its behavior accordingly.

Documenting the architecture and designs in a centralized repository (such as MEGA) is great, but all those diagrams is meaningless if the Solutions Architect does not proactively work with the Development team to help them understand the vision and patterns evangelized in the blueprints. The most efficient and effective way of conveying that information is through informal face-to-face conversations.