Change is Software’s greatest threat, and its defining characteristic. Disagree? How’s that Agile Transformation going for you?
To explore this cognitively-dissonant statement, we’ll chase some waterfalls as we look at what agility might mean to Software Engineering, and the role that “change” plays in it.
Chasing Waterfalls
In the “old days” Software was built with months of requirements gathering and several revisions of comprehensive specifications across various disciplines.
Back when I worked at a prominent ISP, our Product Management group would spend months drafting comprehensive requirements for a new feature or product, into a glorious Product Requirements Document (PRD).
After 7 years climbing my way up thru seniority ranks with a strong track-record on smaller-scale projects, I finally got to lead my first big cross-functional project and earned the honor of producing a no-less glorious Technical Architecture Document (TAD). Rife with Architecture, Entity-Relationship & Data-Flow Diagrams, it also covered:
- Database Schemas
- System load estimations, load-testing & caching strategies.
- Provisional release engineering procedures, to define how we would deploy code to Staging and Production.
- Logging…
