Grappling with Requirement Complexities

For an Architect, as if deciphering the requirements between Functional and Non-Functional requirements was not enough, DevOps and Technical Debt has opened another head for bunching requirements.

For the uninitiated, DevOps is a movement that is meant to break down the silo approach between the Dev, QA and IT teams, where the code moved in a batch mode from Dev->QA->IT Operations teams. This silo'ed approach meant delay, disruption and duplication of efforts, which ultimately leads to delays in pushing out business functionality.
DevOps promote having a integrated team of application development, QA and operations people that shortens the delivery cycles and work within the 2-3 weeks sprint cycle. This means people with multiple skills (read polyglot programming) - either coders with sysadmin skills or vice-verse. Advent of cloud has accelerated this methodology as the team developing the feature is also responsible for its deployment.

With clients insisting on shorted delivery cycles, multiple releases in a day at times means teams need be agile and staffed with appropriate skills to be able to deliver the business functionality.

Damon Edwards explained DevOps very beautifully in a blog post last year:

The most fundamental business process in any company is getting an idea from inception to where it is making you money … The whole point of DevOps is to enable your business to react to market forces as quickly, efficiently, and reliably as possible.

Traditional models of SDLC like waterfall model can not cope with the newer demands of the business. Business wants to try out new features / functionality to guage the client reaction means more releases, more agility expected from the teams.

All this agility, means the code going out is not optimal and can be messy at times. This means maintaining code or adding new features become harder and harder as we progress. All this slows down the sprint cycles.

Technical Debt is a metaphor developed by Ward Cunningham, who drew the comparison between technical complexity and debt and said

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.

If the business insists on reduction of technical debt along with the new features being developed, it adds another layer of complexity to the whole engagements.

Imagine, with every sprint, the team is adding new features ,  refactoring / rewriting the old code (to reduce/payback the Technical Debt) , ensure and account for any new Technical Debt getting added, the job of the architect to co-ordinate and co-relate all these varied requirements become lot more harder.