Defining Done: When to Crawl, Walk, or Run
Join the DZone community and get the full member experience.
Join For Free
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?
Published at DZone with permission of Zac Gery, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
-
A Complete Guide to AWS File Handling and How It Is Revolutionizing Cloud Storage
-
Observability Architecture: Financial Payments Introduction
-
How to LINQ Between Java and SQL With JPAStreamer
Comments