Resident Evil

Do you know about the time-bomb viruses? Those ones which start execution in a certain time frame. Today, I have a similar behavior but this time not a virus. It’s an evil code.

We have an application on the production environment which has been created seven years ago. The project seems to be working properly for a long time with no massive problems. However, an exception suddenly encountered when any user try to edit some data items.

Microsoft VBScript runtime error ‘800a0006’
Overflow: ‘CInt’
/newsline/newsline/dbshell.asp, line 641

The project was implemented in classic ASP and VB script. If you had the opportunity to work with this crappy-style languages, you can imagine how debugging in this kind of code is missy. So I had no way except to analyze the exception getting the most out of it.

If you notice, it’s an overflow exception. This means that CInt has got some large integer number to convert and failed to. After googling, I have found that there is a maximum limit for this method input and it’s 32768. From a second look in the exception, you can see that it happens in a file called: “dbshell.asp”. This leads to conclude that the number this method is trying to convert is retrieved from the database.

This was actually a good guessing. In the production environment and after seven years, some data table in the database reached to have more than 33974 records. The method couldn’t convert any sequence ID for any items with ID larger than 32768. The issue couldn’t be captured in the quality test as this low level test case couldn’t be considered or even thought to be problematic.

The developer who wrote this code from seven years ago didn’t imagine that some day the number of the records will reach this limit. The exception was resident to blow up after these long period. These lead us to an old lesson. At the time of building your application, you don’t think that your application will last for long. You need to consider which data you think will go large and which is not. Hence you follow the appropriate guidance in the implementation.

Code Style Review Using Microsoft Source Analysis

Today, I gave a try for Microsoft Source Analysis aka StyleCop. The tool was internally used inside Microsoft and it’s now publicly released. It nicely integrates with Microsoft Visual Studio with the ability to attach the analysis process with the project build – See this post. The tool scan all your C# code and gives you hints for better coding style according to the best practices followed in writing C# code. It gives for example notes regarding the missing comments, formating, missing or extra spaces, extra blank lines and unnecessary brackets.

Here are some sample error messages resulted after running the Source Analysis on one of my projects

– The class must have a documentation header.
– The property must not be placed on a single line. The opening and closing curly brackets must each be placed on their own line.
– Property names begin with an upper-case letter: projectspath.
– All using directives must be placed inside of the namespace.
– The body of the if statement must be wrapped in opening and closing curly brackets.
– Statements or elements wrapped in curly brackets must be followed by a blank line.
– The code must not contain multiple blank lines in a row.
– All properties must be placed after all constructors.

However, there is some drawbacks regarding the tool like it targets only C# developers. More so it can’t recognize the spelling mistakes in the code and comments which is one of the most common issues. Another point is that the tool is not flexible regarding its guidelines rules. It doesn’t give you the option to exclude a rule in the next time of the analysis scan. For example, it consider putting a preceding underscore in the class private members as a breaking style. However, it is common for most of the C# developers. I think there is already a debate about the best style guidelines for C# coding to follow. The issue even seems to have some historical sides..

I really recommend this tool if you want your team to follow the basics of the C# coding guidelines without caring much about going in details while reviewing their code. It just help you, so that you ignore all the small crappy notes giving all your attention to the real massive mistakes in the coding logic and modules interactions.

You can find more about the tool releases and the future expectations in the Source Analysis blog.

Thinking In REST

REST or WS-*? The debate which will never end. While REST is taking the lead gradually, the community see many drawbacks in using the traditional WS-*. The complexity and overhead in using WS-*, REST simplicity and how they fit the web architecture are always the main points of the argument. REST is simple, that is it. It has nothing to deal with except three things: Resources, Verbs and URIs. The idea of making use of the HTTP standards to accomplish all the needed CRUD operations on the resources is really interesting from the service development perspective.

It was clear from the beginning of the WS-* evolution that WS-* violates and ignores the architecture of the Web. It replaces the concept that the Web is identified by URIs to the concept that the services is identified by WS addresses. However, in the RESTful architecture, all the addressing is through URIs. This creates a homogeneous architecture comparing to how the web is actually constructed. Even dealing with URIs as your default addressing help in promoting your service in the search engines results and making it more reachable by your consumers.

WSDL doesn’t give you much information about the semantic and logical interactions between the services methods. It just provide a listing for the service methods names, parameters and data types. You can’t know for example what shall you need to call first to accomplish a specific task or what this service is actually doing. This is not the case in the RESTful services where you can build you own service documentation. You provide a custom HTTP GET request returning an HTML response with the allowed operations for this specific URI along with any custom documentation you may need to attach. However, you still able to describe your services using the WADL Language – the WSDL equivalent – in case you still need to use a descriptive language for your RESTful services.

Another point to mention is about how REST can make use of the HTTP protocol standards. Suppose you want to make a request to some WS-* service and get the response in several formats. You will need to pass the required response type to the service method or even make a separate method for each type! Neither of the two solutions is convenient. In REST, you can make a solid use of the standard HTTP header. You simply modify the “Accept” field in the HTTP request header with the required content-type of the response. In the server side, you will receive the required content-type in the request header so that you will be able to respond with the corresponding format. This way you save the confusion of your service consumers and make uses of the HTTP header to provide some kind of a separation between the needed request parameters and the other non-related ones.

Another point is about error handling. In REST, you are able to make use of the standard HTTP status codes in a very elegant way. You may respond with standard error 505 for example if the requested resource is not found or with error 401 if you’re not authorized to access the resource. So you have a rich standard protocol to build your own services on.

RESTful architecture starts to get more and more acceptance in the web development community. Microsoft provide RESTful capabilites in its WCF Web Programming Model. Google, Yahoo, Amazon and all the big entities are now digging in the RESTful Services. There is something there you should start to care about.

Scrum in Action

We are now working in a project which have taken more than 6+ months and still in progress. 159078+ lines of code, 80+ page, 120+ user controls, 100+ tables and counting. In projects with such scale, you need to manage and control your development life cycle. You want to decrease all risks and possibilities of failure. Working with Scrum methodology helps a lot in making developers time management more efficient.

I’ll try to state some points which helps us during the development of the project. My recommendation points maybe a part of the scrum definition and maybe not. But sometimes practice is more trivial than science. The following are the concluded results.

Design meetings: In each project you have to design. But as a fact, the design will change. So all what you need is to put the outlines. You don’t have to state all the details. Try to make the design meetings for things which is really need a heavy mind storming and architecture. This includes frameworks, libraries and infrastructures. Discussing the design of each part in the project is a time consuming and won’t help you that much.

Time Estimation: When estimating the time of the tasks, it should be in the presence of your team members as it’s a part of the sprint planning. The sprint planning is usually a long boring meeting. For each task, each member will make an estimate. Then the average will be the final estimate of the task. If some member give an estimation which isn’t reasonable or far away of the others estimations average, you start to ask him why? He may know something in the task which is mysterious, may take more time or may need more resources. Depending on all these discussions you will get a better estimation and better time management.

Another point, if a task will take more than 2 days, you should start to think about dividing it. Most of the uncompleted and bottlenecks in the projects are the long estimated tasks. The estimation of the long tasks are usually not accurate. Even the scrum master won’t be able to know your progress each day if you just telling him “I am still working on it”. Try to divide your task to smaller parts so that you can give it a better estimation.

Daily meetings: The essence of the scrum is the daily scrum meetings. If you didn’t do it daily you will lose process monitoring. The team activity will be degraded. You won’t be able to finish the work on the estimated time. Try to keep on this 15 min. meeting every day. Try to keep these meetings physical as much as you can. I mean here to avoid instant messaging meetings or such stuff. Instant messaging meetings takes much time than the physical ones. People don’t take care about the time while messaging and the scrum master won’t be able to control it. Try to determine a fixed time for the meeting each day – ideally – 15-30 min. maximum – and make sure it doesn’t exceed the time limit.

Code Review: Usually you will need to refactor some parts of your code with your teammates. Code Review Meeting is your way to do that. Problems exists when you try to make “code reviews” as a rule in each sprint. It doesn’t work like that. From my experience don’t do any code review if you don’t have a predefined list of your targets and you really have a problem you want to solve. If you have nothing to review in these meetings, then it will be a hassle and it will be something other than a technical meeting! It will be time consuming and the meeting will end up with nothing. Specify the targets of the meeting before scheduling it. Team members may inform the scrum master if they think there is a part in their code should be refactored in attendance of the other team members.

Design Changes Reporting: Keep all design documents on your source control or repository folder. Make sure that any updates on the designs, flow, sequence diagrams or even requirements modifications are accessible for all the team members. Problems occurred if one of the team members changes something in the design or the flow and didn’t inform the others about it. The best practice is to update your documents with any modifications and commit it in your repository. Not only that but you should inform the others about your modifications and the member you think his work will be affected with your changes.

Bug Fixing: During the sprint, testers may start to test your work of the previous ones. Bugs will be accumulated and it’s not considered as a part of the sprint estimation. You have 2 choices, either allocate a member in your team to fix all these stuff or assign the bugs to their owners. The later option – if not well controlled – will contradict with the scrum rules. The developers will have an increasing bug list and will feel that they don’t make any progress. The solution is to postpone any generated bugs through the sprint to the next one. Testing the work during the development is really a mess . Testers may report some bugs which are features to be implemented on the sprint. Still the bugs should be reported but not assigned to the developers during the sprint. It should be postponed. In the next sprint meeting it will be considered in the developers estimation.

Injecting Members to the Team: You have time constraints and you want your developers to take care of the new features. But in the same time, you have a list of bugs to be fixed. Don’t inject external developers to fix these bugs. Especially if they don’t have enough idea about the project and the requirements. You will end up with a longer bug list!

This is my review about the best practice which makes the scrum process more efficient. Still it’s not that perfect on all the time. Try to modify the process to fit your needs. Although learning and reading is so important to improve your process, but still nothing better than practice.

Dzone – Vote for for this article!
Stumbleupon – Add Your Review

Why Employees Leave Organization?

This is an article of Azim Premji – Chairman & CEO of Wipro – explains why employees leave their organizations – even it seems that their choice in the begining was right. The conclusion that if you start losing talented people in your organization, you should start looking to their immediate managers. As a fact, People leaves Managers not Companies. Humiliation, Stress, being too controlled are all reasons making employees leave. Check out more about the reasons here:

Why Employees Leave Organizations?