Aug 26 2009 10:00AM GMT
Posted by: Jaideep
Software developer,
software development
If answer to the first question is No, start moving into the direction of converting it to Yes. Answer to second question also has to be yes. Let us see what is meant by Imagine, Dream and Innovate and how to adopt them at workplace.
Imagination- The ability to create, and paint a mental picture of a new concept or situation can be defined as Imagination. In your case when you have to write business process in your code, it is primarily important for you to imagine business in right sense to embed it in your code.
Dreaming- Coming up with scenarios or goals that with a bit of work can be achieved. Your imagination of scenarios has to be set as a goal of coding it rightly and then ‘doing’ it.
Innovation- Making the impossible become possible by finding another way around a situation or problem. At times you have to find an alternative to optimize your code or choosing a right alternative out of many for a scenario.
Aug 24 2009 10:00AM GMT
Posted by: Jaideep
software development,
testing,
Development,
software,
tester,
developer,
Software developer
A software division in an IT company is considered to be a profit center whereas the Testing division is considered as cost center. A set of developers develop software, get it tested by a set of testers, sell it in the market and earn profits. The credits and benefits on success of the software never come near to testers.
Let us look at a model where testing is offered as a service that costs. Developers claim their software to be ‘fit’ for market after they develop it and do some testing at their end. If testers now test the software and find out meaningful bugs that could have created a ‘sorry’ situation at customer end, then for each of this ‘meaningful’ bug, some amount should be debited from development division’s earnings statement and should get credited to testing division’s earning statement. And the real cost of product is development cost + bug finding cost + bug fixing cost
Aug 19 2009 11:00AM GMT
Posted by: Jaideep
Software developer,
software development,
unit testing,
tester,
Bug,
product testing,
software testing
If a person who develops software is software developer, why not the same person developing bugs in the software be called bugs developer. How many developers ethically perform the unit testing after completing development of a unit? It could be - None, a few of them, some of them, most of them or all of them. Some of them might be under the impression that they perform unit testing after completing a unit but the way they do it might not be really helpful in finding bugs. It might be just to satisfy them what they do and call it as unit testing.
If developers really perform unit testing, find out the bugs and fix them, in actual, then when testing is being performed by the testers why they have to perform unit testing again? Why can’t the testers skip it and save lot of money and time of the organization.
Aug 7 2009 10:00AM GMT
Posted by: Jaideep
Software developer,
software development,
Application development,
Software application,
software testing,
bug-free,
Bug,
software,
application,
bug identification,
application building,
code writing,
application performance,
business requirements,
Business Rules,
code validation,
business process,
process owner,
end user,
collaboration,
tester,
application functionality,
software functionality,
software performance,
quality,
customer experience,
software build,
bug fixing
Lot of efforts can be saved in terms of time and money if we reach to a stage of ‘first time right’ in application development. It has been proven largely that no good application can be built and released without extensive testing. Testing is not developers’ ball game – this is also a well proven fact. Reasons are many as far as it is concerned that why developers can’t build a bug-free application, or why can’t they test on their own. We are not going to discuss those reasons here. Focus here would be on what developers should keep in mind while building an application that it requires minimum efforts and time in all testing stages. As we all know the cost of bug fixing goes manifold, depending on how much distance (in terms of time and project stages) it has covered after development for bug identification. The bugs identified at a later stage, say during UAT cost more significantly as compared to the bug identified by the developer himself immediately after writing a code. Few qualities if a developer acquires and keeps in his mind while writing codes would not only benefit him but the organization he is working for and their customer also for whom the product is being built.
1. Commitment to application performance should be kept in mind while writing a code.
2. Clarity of business requirements and rules/ validations that are being translated into the application with real aptitude of business and not a developer. Don’t imagine and build. If there is some lack in clarity – discuss, record and build.
3. Treat yourself as the business process owner and end user – and build the application accordingly as if you have to use it. Don’t think yourself as a bartender, think as if you are preparing the drink for yourself.
4. Collaborate and build – rather than building in isolation- collaborate with other developers working on the application, the end user, and the testers.
5. Optimize your code – don’t just write it. There are n numbers of optimizers almost in all technologies. Use them and build a strong application in terms of functionality and performance. Be quality focused. Don’t do efforts that call for more efforts later.
6. Be focused. Don’t work on various applications development at the same time unless it is too mission critical.
7. Gain customer experience after launch of your application. It will certainly help you in your future builds. Build a customer satisfaction metrics.
8. Don’t take short cuts in fixing bugs – whatever stage they are identified. That way you will build more bugs while fixing identified bugs.
9. Work like a champion. There is a difference between playing a shot and playing an accurate shot.
10. Be loyal to yourself, your organization and your work.
