Prashant forwarded me this link that discusses some of the things a developer looks forward for. Pretty much realistic and direct to heart conversation. Some of the points are quite well mentioned and explained. However not all points are agreeable, especially point #9 ( Having few legacy constraints). What I infer from that point is nobody likes working in a system which is poorly designed and buggy. And while implementing something one needs to follow lot of constraints which takes out the gist or joy of writing a software. To approve your fix or new enhancement in a "working" system, you gotta go through series of reviews / meetings (if needed). According to the author, this is what a developer hates. I believe some part of this argument is true ( sometimes we see a strong reluctance from the approver) but certainly there are few things I disagree.
I don't think you always get "bored" while maintaining some legacy software, provided it's not exceptionally stable. One thing is true that some day or the other we have to maintain a software if we want to make money out of it. If you have got customers who pay for your product, you can't just go on pouring your ideas in a working code, you gotta look at the issues of a current system, issues that a customer face while using it. Howsoever brilliant and well tested your software is, it gets a real taste when some potential user uses it. And I believe, fixing those issues do need a lot of creativity. Such fixes might sometime increase your knowledge, who knows, you might come up with a great patch which fixes a nasty bug nobody have ever thought of. On a positive note, you get a great code repository to walk through. We always read and analyze algorithms but in a system like this, you see their real life implementation which is never seen in any book. It's always good to design and code something "from scratch" but to do that I think, one needs to have a great expertise. It's a thing which comes to oneself when one writes and "reads" good code. And such systems actually give us the opportunity to do so.
However, not everything is as rosy as it seems. Sometimes I get stuck at some point and can't do anything. A complete code doesn't help me reproduce a bug. That's because I don't understand why that code is written and don't find a document / note which explains me its purpose. I really get frustrated / bored and all I need is a guy who knows how this works. And once the problem is understood, half of the job is done. To me, reproducing and fixing a challenging bug in a complex system is as fascinating as developing an equally good code.
5 comments:
Yes, maintenance might teach a thing or two but SNR is pretty low I guess..
Reading good code (if such a thing exists:p)can be a good learning experience, but sometimes it might happen that there is something in the code for a particular reason but if I have never seen the problem in the first place, I also don't understand the solution :-D
SNR will depend on things which you are fixing e.g. if you are working on an internet site and some drop down box there doesn't show all the options which it is supposed to show. Here adding such functionality will not be a worthwhile experience. But let's say in a data warehousing appliance, you implement one of the aggregate functions, then that could be a great thing to do...
About second point I agree that unless you understand the problem, the solution is of no use. The challenging part there will be to create a problem scenario from the solution itself :-)
In my experience so far, when I read good code (i.e., hard to understand :)), it pains me to patch it with my for-the-time-being fixes.
Working on the project which is mostly under maintainance has tought me one thing, every project that starts with good and reasonable code base, grows into hard to maintain, patched-up legacy software.
Whats SNR by the way?
- Satish
Leave it. I found what it means on Google.
- Satish
@satish,
That is the real point. The main aim should not be "time being fixes" but a complete full fledged solution. As far as complexity of a software is concerned, it is bound to happen and so are the hardships in maintaining the code base. But that's life, one has to live with it.
Post a Comment