A recent question on StackOverflow reminded me of my greatest frustration as a programmer.
I have a legacy system that is extensively using Groovy version 1.0 and currently I can not update Groovy to an updated version. From time to time I'm getting a PermGen error...
To add some context, the latest Groovy version as of this writing is 2.4.5; a lot has changed since 1.0. Sure, there's a memory-related issue in the question, but underlying it is another problem. A much bigger problem: an evasion of the facts on the part of those who prevent programmers from doing what they were hired to do. The real problem is a hot potato no-one is willing to touch it.
The killer of efficacy
It all goes down like this:
- There is a problem with the software.
- The programmer wants to get in there and fix it.
- The programmer is told Hell no! Leave that alone!
- Confused, the programmer eventually figures out the decision makers are afraid of change.
- The programmer ceases to do his/her best to avoid further scolding.
A valid first question is: Was the programmer's desire to fix the problem right or wrong? To answer this, you have to consider why an employee is employed in the first place.
When you buy a Mercedes, you expect a certain level of quality from the vehicle. Lets call it um... Mercedes-quality. If you end up with say... Kia-quality (no offense to Kia), then you'd be rightfully pissed. On the other hand, if you end up with Lamborghini-quality then you know you've got one hell of a deal. Unfortunately, this reality-oriented way of valuing doesn't always make it through the front door of corporations.
When an employer hires an employee a certain level of performance is expected. Typically compensation is based on the performance delivered by the employee. However, for this to work properly the employer must be capable of accurately assessing the performance of the employee. When the assessment is inaccurate, possibly due to incompetence, then of course the assessment will not reflect reality and therefore will be incorrect; an over-achiever may not get the deserved compensation.
Back to the question, if the best actions of an employee lead to the identification of a problem, and he knows the problem can be fixed, it is completely rational to expect the employee to have a desire to fix the problem. Creating solutions is a means of practicing one's efficacy; one of the most rewarding experiences a human being can have. So yes, the programmer was right.
I don't think I need to elaborate on what happens when a programmer is not allowed to do her job. But I do want to touch on why these road blocks are put up in the first place.
The virtue of irresponsibility
In my experience, issues like the one experienced by that poor soul which posted the question come from one place: fear.
For example, legacy systems were typically developed with poor programming practices, by today's standards that is. Back in the day there was no automated testing. Fast-forward to 2016 and automated testing is abundant. We still use these legacy systems, but instead of giving them the TLC they deserve for their dedicated service, decision makers choose not to touch them in fear they will break in unexpected ways. In reality, they are right in the sense that changes are likely to introduce problems. And due to the extensive manual testing required, making changes is expensive. But the decision makers are failing on one important count: the legacy systems are asking for help, and are being ignored. This is called evasion. If that word sounds ugly, it's because of its implication: the avoidance of responsibility. To put it differently, avoid the problem will not make it go away. To a programmer, a problem is an invitation to apply his knowledge and skills. To be responsible.
Pat yourself on the back
So to you the programmer I say job well done. If only you'd be recognized for your extraordinary ability. You have done well, even if those around you can't or choose not to see it. Don't be discouraged, it's their loss. There are people, whether they are employers, or open source projects, who'd love for you to join them. Seek them out. You have a middle finger. Don't be afraid to use it.