Rob Kraft's Software Development Blog

Software Development Insights

Programmer’s Parable – The Last Minute Decision

Posted by robkraft on June 7, 2020


The software developers looked forward to making the desktop software available for download tomorrow.  They had worked hard to create a high quality, robust program to support customer needs for many years to come.  The business owner stopped by and asked if they had included the discount on purchases for his brother’s company into the software.  The developers looked surprised.  They did not know about this requirement.  The team lead admitted, “I’m sorry, I forgot about it.  You mentioned it to me when we had lunch a few months ago but I did not write it down.”  The owner, said, “My brother will be one of our first customers, can you add this feature today before we release?”  One team member, a mid-level software engineer, spoke up, “Yeah, I think we can make a few simple changes to show a discount in the desktop user interface (UI) only for your brother’s specific account number and it should work fine.”  The response seemed to please the owner, but the software architect replied to the mid-level engineer, “I’m not so sure.  That may create new problems.”  He continued, addressing the product owner, “We will discuss it and get back with you.”

So, the developers held a meeting to discuss the problem.  They estimated they could modify the desktop program in a few hours as the mid-level engineer suggested to solve the problem in the short term, but what if additional customers needed a discount?  A programmer would need to make another code change and they would need to publish a new version as a patch.  And how would that logic get included into the mobile app they intend to release later that year?  They would have to code a similar workaround there.  They would have to maintain the quick fix code in several places.  Putting a quick fix into the UI introduces risks that the logic won’t be applied elsewhere when needed; it would also be harder to automate unit tests for the new logic; and it would require programmer intervention for future similar changes.  Another option, and the one the architect preferred, was to add a column to a table to indicate the discount, change the stored procedures and business objects to handle the discount; and also create a new user interfaces to allow the product owners to configure discounts without programmer intervention.


The developers made quick estimates and presented these three options to the product owners to make a decision:

Option 1: A quick fix.  They estimated a few hours to complete coding and testing the work.  The benefit would be releasing on time.  The drawback would be a design that contained risks that this business rule is not maintained across the entire code base and that additional patches to the code would be needed if the hard-coded discount changed or needed to be applied to other customers.  Another drawback is that the software architect did not favor this approach and there were already concerns that he was getting frustrated with the company and might choose to quit.  The mid-level engineer however favored this approach because it would work, and it would get the product to the customers faster so they could be happier faster.

Option 2: Delay the release for two weeks to allow the team to improve the design to support discounts that could be configured by business users without future changes to the code.  The benefit would be a design that is more adaptable to changes in product discounts in the future and that the product discount logic could be shared with the mobile app.  The drawback is that they would have to tell the customers the product release is delayed for a few weeks.

Option 3: Perform the quick fix, but immediately start working on the improved design to allow users to configure the discounts.  The benefit would include releasing the product on time, and the architect could get the good product design he was looking for.  However, the drawback to this approach is that it would take four weeks to roll out the product fix with the new design because extra work would be needed to version the API due to the changes required to it and also to migrate the database changes from one version to the next as well as to perform all the upgrade and migration testing.

Which option would you chose?

There is no correct answer, but one choice may be better than another depending on the situation.

If the product is a Christmas promotion application for the year 2020, then the quick fix of option 1 is likely best assuming the program will only be used for a few months before it is discarded.


If the product will help its users start making or saving tens of thousands of dollars every day they use it, then you probably want to get it to them as quickly as possible, thus the quick fix of option 1 or option 3 is likely the best option so the gains can be realized even though a higher cost is placed development.

If the development team has other valuable applications to develop, then perhaps you should choose option 1 instead of option 3 because the return on investment (ROI) of another application is greater than the cost and eliminating the risks than come with option 1.  Perhaps the business has another product that will earn a $100,000 per day once deployed.  Should the developers spend a few weeks or a month making the first product better when it only brings in $5,000 per day instead of starting work on the second product that will earn $100,000 per day?  If the profit earned daily is high, then you should probably lean toward option 1.  If the profit earned daily is low, then you should probably lean toward option 2, assuming the application will be around for years to come.  If developer costs are low; particularly if your developers have nothing else they could be doing with their time, then option 3 is probably a good choice.


If developer morale is important and if the decision seems to have a big impact on developer morale, then perhaps you should accept the approach they recommend in order to boost their morale and increase their sense of ownership in the product.

We, and here I am speaking as a developer myself, often desire to fully complete a product or feature we were working on.  There is satisfaction and value in doing so.  But sometimes maybe it is best to leave some code and applications partly sub-optimal because there are things we could be doing with our time that are more valuable to the company.

In software development we often have many factors to consider in making product decisions.  Rarely are the costs and benefits clearly measurable.  Even time spent in analysis causes a delay in execution and therefore contributes to waste and increased costs, so it is sometimes counter-productive to spend a lot of time in analysis.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: