Home » Software Development » Immediate gratification v/s delayed gratification in context of Software

About Advait Trivedi

Advait Trivedi

Immediate gratification v/s delayed gratification in context of Software

This topic cuts across many different disciplines. But here I want to discuss it in context of software development and its process.

Its a proven fact that when an individual focuses his efforts on long term goals he is laying down a foundation for quality life for far and near future. Actions that give immediate returns can hardly give any benefits in the long run. Few examples to put this in context of software process –

1. When an individual starts learning a new tool/process/method which is better than current one he/she faces slump in productivity (for e.g. TDD). This leads to an environment where managers starts thinking that change is not helping. Or simply they don’t have courage to face the initial loss of productivity for the sake of increased long term quality benefits.

2. Focus on process rather than product – Its not unusual that supervisor of a development team will over-emphasize on the product delivered rather than question the quality of process by which product is produced. What they are (un)conciously doing is, focusing on short term goal – they want to see a piece of functionality in action – immediately. If they delay the gratification and say, allow technical team to enforce processes/tools then that will ensure that all future deliverables are indeed quality deliverables. Because they are investing in something which will improve the process – which is responsible for the product.

3. Similar but one which has more drastic implications – before requirements can “sink” in, start the development/design. Today’s software methods and RAD tools allow requirements to change constantly during the project, but its important that requirements “sink” in the psyche of the technical team. I believe there is always a motive for coming up with a particular software requirement. That motive hardly changes, if developers are able to study and interact enough with requirements or producers of that requirements(client ?) they will catch the motive which is alway hidden and never communicated. If design/development happens focusing on that motive, the deliverables will be able to better accommodate requirement changes.

Obviously the catch lies in deciding in when to stop being invested and take the yield. But unfortunately software teams today try to take the yield way before they have invested enough and hence they don’t get good enough yield.

Reference: Immediate gratification v/s delayed gratification in context of Software from our JCG partner Advait Trivedi at the CoolCode blog.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
Email address:

Leave a Reply

Be the First to Comment!

Notify of