Defining Done: When to Crawl, Walk, or Run
While programming, developers cross many decision points that bring into question a different, lower-level definition of "done." For instance, how far should something be architected? Scaled? Fault tolerant? Another example is fixing a bug. How far does one go to fix the problem? Should the surface level issue or the underlying problem be fixed? What happens if fixing this issue exposes/creates other bugs? Although some of these questions can be answered through fact finding missions, others are less concrete. When these situations arise, keep the following thoughts in mind:
- Can direction or advice be provided by a lead, manager, business analyst, stakeholder, etc.?
- Is the complexity of the development approach less than or equal to the value of the functionality? For example, a seldom used admin page may not require the same level of attention as other high traffic areas.
- Which area of programming does the functionality fall into? Good enough, solid, or reliable?
- What is the priority of the concern/problem? Does this need a short term or long term solution? Or both?
- Do other priorities supersede the importance of this?
- What are the risks of going with that decision? Are other risks exposed by not selecting that decision? Will/does this negatively impact the software? By how much? Is that within an acceptable range?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)