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.
