Build for Immediate Use
When building a reusable asset it is natural to anticipate future needs and provide the flexibility for various client usage scenarios. Before you jump in and code every single feature – pause. There is a reason why agile practices recommend iterative design and discourage BDUF (big design up front). With systematic reuse, it is more important to get aligned to multiple projects and applications rather than build the perfect asset. Obviously, if you have a window into your next iteration’s needs or another project’s requirements, you will want to accommodate them. By the same token, if you don’t have a good idea what the future is going to bring – don’t add code and bloat the codebase.
The good news with improving a reusable asset is that it will benefit not only your new client but also existing clients. With that in mind, strive to address the absolute must with a reusable asset. For example, if you are creating a new standardized service to provide customer data – consider the many aspects to vary and facilitate reuse. You can:
Offer multiple flavors of the service’s data – a set of minimal fields, a “most common” list of fields, and a fully populated flavor that returns all data.
Offer multiple versions of the different flavors – e.g a getClient_v1_0 and getClient_v1_1
Vary the output format returning XML, JSON, serialized object, or even RSS feeds
Provide localized data (formatting, replacing data per a geographic locale).
Support a variety of transport interfaces – HTTP, JMS, FTP etc.
Given these options above, it is tempting to build that ultra-flexible reusable service meeting all the needs of today and tomorrow. However, projects have deadlines and business imperatives – it is critical that reusable assets don’t jeopardize business objectives. Build a sub-set of the above that is absolutely essential for your immediate deliverable. Be ruthless with code that is unused and unnecessary. Your project might only need to support JSON response over HTTP – so build just that and nothing more. You can use design practices, patterns and refactoring techniques to decouple your code appropriately (e.g. separating business logic and formatting logic). This will position you for extending the codebase in the future.
Last updated