Compromise in Programming to Maximize Value

Every programmer that builds software products for a living has experienced or eventually will experience a fork in the code road. They can either be satisfied for now with the feature they just built and move on to the next task, acknowledging that the feature has room to be improved upon, or they can keep on building to make a feature better (and better) (and ooh what if it could...).

To compromise or not to compromise?

For me, a person who wants to finish video games to 100% and who grew up reveling in finishing my meals completely so I could be part of the Clean Plate Club, my instinct is usually to keep at something until it's completely done, to the best of my ability.  However, sometimes compromises can lead to better outcomes.  We all have limited time in our lives (and limited room in our stomachs, except when we're teenagers), and spending it intentionally is important.  Likewise, clients paying for a software product's creation or maintenance will typically have limited funds available for that purpose, which often loosely equates to a limited number of hours they can pay you to work on their project, and every client will want maximum bang for their buck.  They'll want to maximize the product's value with the money they spend on your development efforts.

So as programmers, when we get to these junctures, we should be considering a bigger picture than just this one feature and its quality/robustness/ease-of-use/flexibility/etc.  Which factors should you consider when deciding where to compromise?

1. Requirements- First and foremost, is there an agreed upon or contractual set of requirements for this feature? If so, you'd better meet those requirements at the minimum (and in some cases, the maximum).  It is often a good practice in software development to get client approval (or feedback, modifications, then approval) on a feature's requirements when they get planned out, before the more costly work on that feature begins, so you can avoid having to make assumptions that might be incorrect, which could lead to having to rework something built differently than a client's vision.  Ideally these agreements and plans can be iterated upon and re-approved so they incorporate the latest pivots the client or the architecture might require.  Agreed upon requirement documents tend to align everyone's visions for the product in writing and ensure the expectations for the product aren't constantly moving targets.  Depending on the size of your team, you may have a Business Analyst to do a lot of this gathering and documenting of requirements for client approval, but even if you don't, that process can still be very helpful.
2. Priority- How does this feature rank among other features in terms of leading to or being necessary for success of the product or company? If it’s close to the top of the list, you'll want to make sure it fulfills each of its purposes very well, looked at from each relevant perspective.  If not, maybe jot down enhancement ideas and put them in a backlog to be considered in the future and move on to implementing or improving features more critical to success.
3. Effort- How much time do you think it would take to add your considered enhancements and is the value worth the effort/cost? You may have three separate improvements you'd like to make, but only one or two of those would provide enough value to make spending the necessary effort worth the cost.  When in doubt, communicate with the client (through the proper channels if necessary); just be careful not to overpromise or phrase questions or statements in ways that imply the additional enhancements would be free of cost, and do make sure everyone who needs to know about the decisions are informed (put things in writing after verbal meetings and share those decisions with interested parties).  It is easy for these sorts of misunderstandings or disagreements on priorities or miscommunications to sour an otherwise great client relationship, so make sure communication is handled well all around.
4. Usefulness- How important would your considered enhancement be to the success or happiness of typical users of the feature? Can they do without it, or would it be important or even crucial to them?  Happy users often lead to happy product owners. These sorts of talking points where you can be an advocate for the product's typical users should resonate with the client when a feature is planned or discussed.
5. Frequency- If you're making a change that would enable a popular or common user task to be accomplished in less time, who could that saved time benefit? A minute saved, or even a few seconds saved, multiplied over hundreds or thousands of occurrences or more, can make a huge difference on a regular basis to the people and companies who benefit from the time saved.  On the flip side, if the feature isn't going to be used frequently, the value of such an enhancement may be low.
6. Perspective- Consider all relevant perspectives (various types of users, various client entities, various partners, etc) and what value the enhancement would offer to each of those entities. Putting yourself in others' shoes to look at things from their perspective is a key quality of excellent programmers and it’s useful in helping to make these sorts of decisions.
7. MVP- Lastly, when in doubt, just limit your implementation to the core crucial functionality of a feature, and document or backlog ideas for enhancements to be looked at in future iterations on the product. It is quite often best to get a Minimally Viable Product (MVP) in the hands of the client and of users before building out extra bells and whistles, especially when you can apply user analytics and receive user feedback.  You may be surprised by user feedback and usage; sometimes you or your client may consider a feature vitally important that ends up almost never getting used by the users or may consider a feature insignificant that the users find indispensable.  User feedback and insights about usage, especially early on in a product's rise, are often excellent tools for determining where to focus effort next.

Long story short, try to consider the product and company as a whole and what is most important for their success, as well as various perspectives, and feature/enhancement expected value and needed effort, among a variety of other factors when deciding whether to compromise on a specific feature's implementation.  To compromise or not to compromise?  As with so many situations in programming, the answer is: "it depends".  Hopefully now you're better equipped to evaluate each situation and to communicate and document what's needed to both improve the happiness and success of clients and to maximize value from your programming time.