21 Mistakes Developers do while Coding.
1. User Input Validation
Whenever we input information on the UI, some of the user input is used for extracting information from the server, For example: Search screens etc. If the input is not validated then it can be used by hackers to extract sensitive information from system/inject malicious data.
One of the most common errors that developers do is not testing the boundary condition of a text field in the UI. For example: Maximum length of a text field, minimum and maximum value in an integer and float field, etc.
2. Browser Compatibility
Developers tend to forget testing the web application on multiple browsers, most of the times application that works on Google chrome tends to break on Mozilla or IE. We cannot restrict users from not using different browsers or restricting them to a specific browser, this reduces the flexibility of the system. Therefore it is very common that the web application will be tested using most of the commonly used browsers Chrome, Firefox, IE, Safari. Still developers tend to forget implementing browser compatibility in the first place.
3. Application Resolution
While developing an application, developers must consider the most common screen resolution of the intended target audience as a result they can decide the most suitable web page width of their website/web application.
Visiting a website where you need to use horizontal scroll bars to look for information you need, as the page width does not fit in your browser reduces readability and is really annoying.
4. Error Handling
Have you seen the page breaks “gosh I hate them”. Poor error handling is responsible for page breaks and website crashes. Developers tend to follow the lazy approach of programming and forget to catch junk which leads to a crash, really embarrassing.
5. Exposing sensitive information/Directory Listing
As a professional tester Integrity of the application counts a lot for me,
Once I right clicked on one of our product websites and checked what is in the source and to my surprise I saw hidden variables storing values that a novice hacker would easily understand and make a hole in the application. This really sabotages the security of the application and exposes client data to the public.
A stable application does not always mean a safe application and vice versa ;-).
Another similar incident that we faced recently, one of our web applications that was in production we were able to see the entire directory if the web server from the browser. The solution to this was a small configuration (setting the directory listing false in the IIS).
All these boils down to one big issue security and integrity of the application.
6. Code review
Code review is an important part of the development process, and must never be compromised.
In order to meet time lines we tend to forget this important process, however some of the most important benefits of code review (can be easily googled) tend to reduce number of defects in QA and UAT there by helping us delivering on time, educates other developers in the team, makes sure that team is following best practices.
7. Understanding of the business requirement/CR (Change Request)
When it comes to requirements developers need an interpreter as if the requirement is written in a foreign language, some even expect the privilege of translating the requirements in the local language.
Damn (I am not intended to write such words) but this really makes me furious. Forget about following the latest version of the requirement document, they even don’t know where the requirement resides. Just implementing a so called functionality isn’t the end of the development process. And the end result lots of reopens and reworks.
And even if they know the requirement, sadly they tend to read only their portion of the requirement document and have NULL knowledge of the full requirement. The expectation is that irrespective of what who is building everyone must be on the same page w.r.t the end to end requirements.
8. Project Design/Architecture
Most of the developers do not understand the project architecture and design, they blindly implement their module.
It’s like carving a door without knowing the size of the wall where the door needs to fit in.
In order to bring best out of it proper Architecture or Project is highly essential.
9. Domain Knowledge
While we are talking about project requirements let’s talk about domain knowledge. Developers tend to boast in interviews and personal introductions that they work in blah-blah domain but how much do they know about their domain?
Unless users have minimum knowledge about their domain it’s impossible for them to deliver error free application.
However developers put minimum effort on gaining domain knowledge. This is where much of the gap is created between what is expected and what is being delivered.
10. Page refreshes/Performance analysis
One of my recent experiences in one of our applications when it came to the QA cycle, I used to see the AJAX loader gif more than the application itself.
You may be using the most advanced technology, but what really matters is how you implement it, if you implement it properly it is a boon else it is a bane.
Performance is something that the developers tend to ignore and the end result is an application, that keeps on loading which is really annoying. Users get crazily mad when it takes 15 mins to generate a 5kb report.
Especially for applications that process a lot of information for example insurance and banking based applications, performance matters a lot.
11. Unit testing
Go and ask any developer what is the meaning of unit testing and I bet 90% will get it wrong. No one writes test cases and just test it from the development perspective and not from an application usability perspective.And even if they do, they do not document it as a result the delivery is at stake.
They don’t see the application from the perspective of the end user.
Developers tend to unit test only their portion of code impacted areas and do not test the entire application.
Documentation is one of the most important parts of the SDLC process. Many clients audit their applications and require SDLC compliance before the project can go live.
Documentation also helps in providing support to the application when project goes live. However documentation is the most ignored pieces of the development process. As a result the knowledge is not shared among fellow developers of the same project as a result dependency is created.
13. Patch Fixing
Whenever the time lines for delivery of project are coming close, developers tend to adopt the strategy of patch fixing.
Patch fixing is a process of implementing by hook or crook, you forget all best practices. This usually results in bad coding, performance implications and downstream impacts.
14. Dumb Impact Analysis /Break X to Fix Y
Developers do not do proper impact analysis while fixing defects. Especially while fixing production defects developers tend to ignore the other implication of making a change to a line of code as a result it definitely fixes the defect but ends up opening up a dozen more.
Developers must be educated to do proper impact analysis of code changes they make.
15. Server File Clean Up
Many a times developers implement error logging mechanism that creates log files in the server, however forget to clean up as a result it eats up a lot of space in the server. We all know how much costly space has become starting from space on land to space on the server ;-).
Another similar scenario where in an application generates reports, whenever the reports are getting generated, there is no reason why it must be stored in the server unless the requirement says so. If not cleaned time and again tend to clog the space in the server.
16. Blindly copying codes from internet
Had there been no Google life would have been a bit less easy, and when it comes to development, I don’t have the statistics of exactly how many developers depend on Google for development.
But maximum of them tend to copy and paste codes from internet without debugging them and making sure it doesn’t have any licencing implications.
17. Code merging: The Monster
Code merge comes to picture where in multiple teams are involved in the development of the same application and I tell you that’s a real big deal for the developers, they merge code at a very late stage in the development process. This introduces a lot of bugs and impacts a lot of existing codes and hence results in re-work and more QA cycles.
Many a times developers tend to do manual merging which results in missing of codes. Rather proper merging tools like subversion must be used for merging.
18. Use of Version control: That’s easy unless you know it!
Keeping track of the code changes is an important piece of development process. Many a time’s developers rely on physical back up of code/solution files.
It’s difficult and tedious task (As my Developer friends says) to keep physical back up of development files rather a proper versioning tool like subversion must be used to keep track and hence the code is always safe. There is no need to keep physical back-ups and hence no dependency.
Also by use of proper versioning tool code merging is easier and multiple inter dependent projects can be easily handled.
19. Code Packaging/deployment: Big deal!
Ahh! the packaging bit, such a pain!
Many good developers tend to do faulty packaging. As a result wrong codes get deployed to the higher environments resulting in lot of bugs and impacting timelines.
In such a scenario many a times it takes a lot of time for the development team to find the root cause as the issue will be not re-created in development environment. And after wasting lots of hours they would find out that the bug was by sending the wrong version of codes/supporting files.
20. Ask a Tester: By the way what do I need to implement?
I have seen many a time developers walking to the members of the QA team asking, what is the requirement that they need to implement, blah-blah. Understanding the requirement is not just the task of the testers; both the team (DEV and Testers) must understand the requirements well. There must be discussions between the 2 teams so both are on the same page.
However I do not support the idea of one team skipping a task as the other has it readily available, this is lazy and lethargy behaviour. This behaviour is quite common these days and must not be supported.
21. Estimation/ Time
Many a times the actual hours spent in fixing the defect is much more than the actual estimated hours. This not only impact the development timelines this also impacts the overall project schedule QA/UAT effort is impacted.As I said earlier proper analysis is not done during estimation phase.