Revisit Assumptions

It is natural to get comfortable, perhaps too comfortable, with the state of your codebase. After all, it works and is probably meeting tangible business needs. However, if your team has to get the full value out of it – the fair and ongoing return on investment – you have to constantly revisit assumptions about the software design and implementation.

Challenging assumptions has a number of benefits for systematic reuse. It opens up opportunities for refactoring assumptions that are no longer relevant / required (e.g. state information has to be saved for recovery). What if that capability is available in your enterprise through another component? Can you swap your implementation? If not, why not?

Similar opportunities exist on both technical and functional sides – the software is always accessed from the app’s web UI (assumption that might have led to code tightly coupled with presentation logic – business rules implemented alongside HTTP header parsing logic). How about assumptions regarding public APIs, nature/sequence of method invocations, client / calling platform, etc.

These assumptions must have made sense and would have been made for a sound reason at the time the codebase was conceived. Question is – are they still relevant? does the code need refactoring to get rid of native implementations or needs to be decoupled from logic that will make it more reusable? All these questions need careful and thoughtful consideration.

Have this discussion as part of your iteration retrospectives, team discussions, and informal conversations. You’ll be surprised about the quantity and quality of assumptions that are holding the codebase back.