3 ms·

I enjoy some maintenance, though I don't want to only do only that. It's quite different from the amazingly rapid pace of fresh empty-text-file blue-sky develo

I enjoy some maintenance, though I don't want to only do only that. It's quite different from the amazingly rapid pace of fresh empty-text-file blue-sky development. In the referenced article though, the person was told he was not allowed to do any proactive refactoring and was only permitted reactionary last minute emergency fixes to bug reports (to paraphrase and expand on what he said, but I am fairly sure this is accurate). That... is a very unpleasant and counterproductive set of restrictions. Without those restrictions, maintenance can be used to gradually convert a giant mud ball mess of hectic changes and poor architectural choices into a robust foundation for future development and a well documented code base that is a joy to work with. With those restrictions, you're constantly putting out fires with a blanket and a bucket of water, but not allowed to buy a firetruck, pass construction safety codes, or establish a network of fire hydrants. Back to the person in the referenced post, given that he is currently the sole maintainer of 4 different mudball applications, has written 4 applications there from scratch, and has 2 new apps under development and 5 more scheduled immediately after, and will be responsible for maintaining all 15 apps, he is clearly very talented and will soon completely burn out. But for him all these details are completely irrelevant anyway. The only important part of his post is this: "My salary is almost equal if not lower then that of a cashier at a supermarket." This is the most important thing he has said and makes the next step he should take clear, and all these details about maintenance unnecessary details.

gbog 14y ago
I agreed with you until "[Salary] is the most important thing he has said". For many people salary is not the most important thing in life. If this guy learns a lot doing what he does, salary considerations could be secondary for him. And I think there is a possibility that he is in a position to learn the hard way (in a way he will not forget what he learnt) some of the nasty parts of software development: code base is awful, touching one thing breaks unrelated parts, doing a simple change takes days because of duplication, PM do not care a shit if code is clean or not and don't want to hear about refactor. All of that is crude reality. Only after having endured such evils can someone really understand why duplication is bad, why hidden dependencies is evil, and, even more importantly: How and when to tell or, more often, to NOT tell a PM that you WILL refactor the code before doing this fix, for everyone's sake.

gbog 14y ago

I agreed with you until "[Salary] is the most important thing he has said". For many people salary is not the most important thing in life. If this guy learns a lot doing what he does, salary considerations could be secondary for him. And I think there is a possibility that he is in a position to learn the hard way (in a way he will not forget what he learnt) some of the nasty parts of software development: code base is awful, touching one thing breaks unrelated parts, doing a simple change takes days because of duplication, PM do not care a shit if code is clean or not and don't want to hear about refactor. All of that is crude reality. Only after having endured such evils can someone really understand why duplication is bad, why hidden dependencies is evil, and, even more importantly: How and when to tell or, more often, to NOT tell a PM that you WILL refactor the code before doing this fix, for everyone's sake.