Showing posts with label Software Development. Show all posts
Showing posts with label Software Development. Show all posts

Sunday, July 5, 2009

Effects of Internet on developers : Positive or negative?

I have been thinking recently about what effects the explosion of information on the Internet has been having on software developers and how it has been shaping their skills. On the one hand, one can argue that it has helped them immensely in improving their knowledge and broadening their horizons. It has also helped them in getting answers to their problems quicker than ever, specially with forums like StackOverflow and having an abundance of search engines like Bing and Google to get relevant links at the click of a button.

On the flip side though, it has also in some ways made it less likely for the developers to feel the need to investigate into their problems and do thorough debugging and troubleshooting. All they need to do now is to copy paste the error in their favorite search engine and get links to web pages directly giving them the workarounds and resolutions. Even though this does improve their productivity in the short term, over a period of time it always helps for developers to troubleshoot the problems they face. This would enable them to understand the system better, get familiar with the quirks that almost any system typically has and also, the researching that goes on in resolving the problem also helps them to learn more. This blog post also talks about a similar problem being caused by search engines but for people in general, not specifically for developers.

I think that in today’s times, where developers’ time comes at a premium, there has to be a middle ground that needs to be chosen by the developers. It certainly helps and makes sense to make use of the search engines and developer forums to get answers to get unblocked and resolve problems. However, instead of doing a search the moment a problem is encountered, developers must try and see if they can find the resolution themselves and invest time in troubleshooting as much as they can afford to. Only if they cannot get a resolution and time is running out, should they look it up on the Internet.

What do you think developers should be doing? Would trying to troubleshoot it themselves help or should they just give importance to saving time and resolving problems as soon as possible?

Sunday, January 11, 2009

Beware when Copy Pasting

Often times, a developer needs to copy code from one place and paste it at another place, followed by some minor modifications at the destination. Of course, copy pasting the same code at multiple places such that no modification would be needed isn’t a good practice and essentially, the developer must refactor and move the common code into a function and insert function calls at the appropriate places.

There are many scenarios where the former operation is required. Even though it is at times possible to move slightly variant code into a separate function and use parameters for the differing functionality, this might not always suffice for a multitude of reasons. The code might be getting used only in a couple of places for example. In such cases, the best way to reuse code is to copy paste. However, from my experience, most errors (often times so stupid that you won’t suspect them to be the cause of problems) occur when one forgets to make a particular change after pasting the code.

One major reason why one tends to miss one or two modifications is that a very minor/no change is needed when doing such reuse (of course, if major changes were needed then one should prefer rewriting code instead of reusing). So people just assume that no change is needed and leave the code as is. Some of the changes that are needed frequently include,

  1. Change of the value of a enum
  2. Change of index variable
  3. Changing the index value.
  4. Needing to declare a variable which was available for use in the copied code but not present at the place the code has been pasted.

Forget these kind of changes and you would spend another hour trying to find the issue and fixing it. Hence, be extra careful whenever copy-pasting code to be able to make the most of the time saving gained from not having to write the code again and in case some error crops up after you pasted code from somewhere, the first check you should make is whether the minor changes like the ones for variable names etc have been taken care of.

UPDATE : After discussions with Dinkar, one important point came up which was that such errors are more likely in Weakly typed languages for obvious reasons.

Tuesday, October 28, 2008

Importance of sending Status Reports

In this post I would like to highlight the importance of having a habit of sending regular status reports to your manager and also, if need be, to your immediate team.

I generally send out the report on Friday evenings so that the manager has an idea of what happened during the week, before that week ends. One can also send the report on Monday mornings but then, that would, theoretically at least, mean you are communicating to your manager a tad late. Status reports that I send out contain 3 main sections :
  1. Activities completed this week : What were the things you worked on and managed to complete this week (do not include items that you are still working on and haven't completed, those will go into the next section)
  2. Actions items for next week : What things are you planning to work on and/or complete in the following week
  3. Blocking issues : This is the most important section that you should send out to your manager. Communicate clearly issues that restrict your progress and follow up on them to get them sorted out asap

Given these sections, one can either send out a simple list of activities for each section or have multiple columns under the first 2 sections to be more elaborate. The columns that I include under the first 2 sections are :

  1. Activity : The activity that you completed/are going to complete in the following week
  2. Effort : An indication of the effort needed for completing an activity (if that activity falls under the first section) or an estimate of the effort that will be required(for activities that are part of the second section)
  3. Main challenges/points : Highlight the main technical issues that had to be /will need to be addressed/solved to complete the stated activity

The big question in your mind would be, why should I waste somewhere around half an hour every week in sending this to my manager, who might not even give it anything more than a cursory glance. Well, here are some of the reasons why that half an hour will be a time well invested :

  1. When you sit to jot down the activities, it helps you to get an idea of how much work has been done and allows you to get an understanding of how efficient you are being at what you are doing. You will be able to catch early signs when there is a need for you to pull up your socks and work harder.
  2. Jotting down the action items for the coming week streamlines your work and thinking
  3. Highlighting the blocking items gives you a better chance of getting it resolved sooner so that you can get back on track with your work
  4. If you organise your status reports in a separate folder (like I do using Outlook rules), you can just take a look at the status reports to get an idea of what all work you did during any given time period. This will prove priceless when you sit down at the year end to fill up your performance review.
  5. Finally, and probably most importantly, it's your chance to show off your efficiency and abilities to your manager. Thanks to this post for highlighting this point

I agree that some of these advantages are already inherent in software development methodologies like Scrum, but there are plenty of other reasons, as can be seen from the list above, for you to use regular status reports. Feel free to add more advantages or some of the best practices you follow when it comes to status reports. Also, share your views if and why you think that sending status reports is a waste of time.