# Iterate, Iterate, Iterate

You want to make sure that you don’t spend an enormous time trying to build the perfect reusable asset. Be it a component, library, or service. Regardless of what you are trying to do accept that you won’t be perfect from the get-go. Instead design for reuse iteratively by [delaying commitment](https://vijaynarayanan24.gitbook.io/art-of-software-reuse/process/delay-commitment) (see [iterative steps](https://vijaynarayanan24.gitbook.io/art-of-software-reuse/process/iterate-iterate-iterate) to build a reusable asset).

![](https://554308880-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M582UGYGD2c_w9yDn9h%2F-M582WQ-8b_WXXwU287f%2F-M582ffyIkQdZaiox7bW%2Fiterate.jpg?generation=1587142378819616\&alt=media)

Iterative design is needed to not only deliver incremental functionality over time but it is also a handy technique to address a key risk with systematic reuse – schedule risk. In a typical enterprise project there are a lot of moving parts – there are multiple stakeholders to satisfy, several teams including infrastructure, operations, production support staff to co-ordinate with, and ensure legacy systems and processes will not be negatively impacted. Given that most projects are delayed you don’t want a reusable asset to make matters worse. Designing for reuse is often mistaken for making software that is too generic or abstract. It becomes easy to slip into philosophical arguments about levels of abstractions and layers of indirection. *It is tempting to lose sight of the business problem and pursue perfection for the sake of technical elegance.*

Here are some warning signs that you need to watch out for:

* Your developers are debating endlessly about a possible future use case that a component or service needs to support at the expense of what is currently known and required
* More meetings are being setup to design the ‘right’ interface to make sure you are guarded against future changes to a service or component
* You seem to be bogged down trying to figure out whether or not to support variation for a particular product feature.
* Your developers are working on designing a business component that has no traceability with what your business user wants
* There are endless discussions about whether or not a piece of functionality needs to be made reusable

When you smell this sort of behaviour, you want to pause, look back, and refocus on the deliverable at hand. Pursue iteration, not perfection.
