Image: Danilo Rizzuti / FreeDigitalPhotos.net
There are two questions that should be asked of each developer involved before a new software product is launched to clients:
- Are you proud of the product you created?
- Would you enjoy using it and/or recommend that your family/friends use it?
Asking yourself these two questions while developing and testing the product will change how you program and benefit the project immensely. Why? You must write good code to be proud of it. You will be motivated to do it right the first time. You will think about how your code impacts your reputation as a developer. Also, you must know how you and others would use the product to answer YES to the second question. The best written code won't help anyone if it is for a useless feature. The best written code won't matter if the whole thing becomes painfully slow to use. If their are reasons you don't enjoy the product and love it, then those should be called out sooner rather than later. Answering these questions honestly will reveal problems that testing didn't catch because nobody knows the product better than the developers. If you answer NO, then you should have some specific reasons why. Those reasons for the NO should often become the priority one (P1) issues to fix.
So often, right before a project is to release, only the testers and the managers decide if something should go live. The attitude is almost like, "Thank you Mr. Developer for your work, now we'll take it from here." A few developers will secretly cringe in horror (or internally panic) when it is decided to launch. They have been feverishly working on P1 bugs from the QA team while other severe problems in the product remain unaddressed or untested. Often QA's P1 bugs are, in the developer's opinion, the P5 bugs. Also, there sometimes is this feeling of an adversarial relationship between testing resources and developers as bugs found create more work for developers and bugs missed reflect poorly on the testers. By involving developers in the go-live decision, they are automatically held more accountible for problems in the live code, after all, it got their stamp of approval along with testing and management.
2 comments:
I really like this! I have been involved in several projects where developers knew about bugs that people found day 1 of the launch and it was pretty maddening. Why didn't you fix that bug if you knew about it?? Probably because I didn't ask them those questions...
Developers are usually lazy and don't like to create more work for themselves, however they often also have huge ego's and will spend hours and hours to fix a problem with their code that makes them look unskilled and foolish. A developer will feel more valued when they are given power to halt the launch of a project, and also more accountability when they do agree to roll it out. A good tester has to balance between nagging developers to death with nit-picky issues and failing to find the important bugs developers have missed but users would be frustrated by.
Post a Comment