Pair Programming

Recently I had to work with my colleague on some software development tasks. What I learned from the pair-programming is to identify the areas of my weaknesses and the things where I had to stress harder to overcome my shortcomings. Not every developer is perfect, so it's a good idea to share your code with other developer, review others code, work on some task as a pair for sometime. Some developers are good in architecting applications, some are good in designing the front-end, some are good in databases, some are good in optimizing applications and so on. Pair programming can give you a chance to learn from others, to fill their gaps by your skills, and keep you going on the track. It can give options to brainstorm on certain areas while you do pair-programming. You can try and see you can benefit from pair-programming or not. I am sure you will.

How to Avoid Deployment Chaos

I have seen several time when the changes on a custom software works perfect while we run on a development box but when it comes to the deployment stage, it does not behave the way it should be. The better solution to overcome such issues is that we should deploy the changes to the similar environment as of the live one. If the application is hosted on a web server and utilizes the database, we should have the same configuration and same database (ideally with the same data and files) on the QA box.
So, start with configuring the web application and copy the application files from the live box to the QA box. Then restore the live database on to the QA box. Verify if the current application is running fine the same way it is running on the live site.
Now, start deploying the database changes and verify if the changes are OK. After that, deploy the web application changes to the QA box and verify if the changes are deployed successfully or not.
Now, test every change on the deployed version and fix if there are some issues. Once every fix is in place, and the new changes are working fine, deploy that on UAT box. Now, let user play with the changes untill they are satisfied with the new release. Once they are happy, deploy that release straight onto the live box. That's it!
I hope this process will minimize the deployment chaos unless you bypass the QA and UAT phase.

Should We Refactor Old Code

Technology is growing so fast that if we do not keep us upgraded, we may stand far behind in the techno race. Every developer will agree with this that he can code a better solution whenever he looks back at his code after few months. Someone may disagree by saying that why should he touch the stable code. Let me explain this with an example.

Suppose, you have coded the following script in your SQL Server stored procedure.

DECLARE @unitPrice int

DECLARE @qty int

DECLARE @total int

DECLARE @grandTotal int

SET @grandTotal = 0

DECLARE cursorTxn CURSOR FOR

SELECT unitPrice, qty

FROM Transactions

OPEN cursorTxn

FETCH NEXT FROM cursorTxn INTO @unitPrice, @qty

WHILE @@FETCH_STATUS = 0

BEGIN

       SET @total = (@unitPrice * @qty)

       SET @grandTotal = @grandTotal + @total

       FETCH NEXT FROM cursorTxn INTO @unitPrice, @qty

END

CLOSE cursorTxn

DEALLOCATE cursorTxn

This snippet works fine, calculates the correct grand total of all the transactions and return the result to the caller. One can say that it is a stable procedure and does the job well. However, if he checks his code after few months and he has already polished his skillsets, he may call this piece of code a crap. He can easily upgrade this piece of code by using the following alternative.

DECLARE @grandTotal int

SELECT @grandTotal = SUM(unitPrice * qty)

FROM Transactions

The above code will return the same result but in a much optimized way.

So, instead of rewriting your code, do refactor your code.