Past wisdom in software development held that the proper sequence of events should start with perfect requirements, followed by perfect design and planning, ending with implementation. The flexibility promised by agile methodologies of software development, according to that view, is as costly as deciding the kitchen in a half-built house is not in the desired location. Besides, what is the meaning of software architecture if we allow for shifting designs and evolving features?
To answer that criticism, one must examine the underlying concepts supporting traditional waterfall development:
• Perfect planning is possible;
• Change is inevitably costly
• Architecture must result in rigid unchangeable results
Perfect planning isn’t possible. It is a disservice to the client to impose upon them the requirement of a perfect plan or the acceptance of an undesired result, if an alternative is possible. In the real world, knowledge of the business is dispersed among many stakeholders, concepts suffer from varying degrees of vagueness, and the desired outcome often begins to crystallize after the work has begun. It is therefore more cost-effective to have the right technical talent that can function in an interactive environment with the stakeholder, and adapt the work to an evolving plan.
Secondly, change isn’t always costly. The cost of change can be minimized if enough flexibility was implemented in the solution in the first place, which is why planning a functionality must include the feature of making said functionality changeable and not set in stone. The extra initial cost in doing that reduces the risk of a higher cost being incurred at a later stage.
And lastly, architecture does not equal rigidity. Proper software architecture makes use of techniques that reduce dependencies, generalize software components and anticipate changes in the design itself. To compare that to the half-built house analogy, the ceiling is not resting on too many walls, and the infrastructure for the kitchen is in many places in the house.
The practice of writing flat, unidirectional software, based on the theory of the perfect plan has resulted in legacy software that is hard to change, maintain or understand. The evolution of the software engineering discipline is in part a response to that problem. The common threads in modern software design concepts indicate that.
For example, the concept of encapsulation in object-oriented languages, where the inner workings of a software entity make that entity a black box that can be replaced without having to change its context, directly serves the need for flexible architecture at the lowest level. The concept of “pure functions”, in functional languages, where a function is by definition unable to change its environment (making the function easy to “unplug” and replace), also serves the same end result.
Proper architecture also makes use of established and proven design patterns, selects the right patterns for the task at hand, and adapts them when needed based on the specifics. This increases the effectiveness of the planning stage by a) avoiding reinventing the wheel, and b) greatly reducing the number of possible paths that need to be explored to a select known few.
It takes a certain attitude to embrace the agile approach: one that thrives on innovation, freedom and work that never stops improving.
Kal Nasser is a software developer with X by 2, a technology company in Farmington Hills, Mich., specializing in software and data architecture and transformation projects for the insurance industry.
This piece was exclusively written for Insurance Networking News. Published with permission.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access