Finally a java collections library that takes advantage of java 5 features to make code more expressive and concise!
Some quick examples: Coding in the small with Google Collections
Wednesday, November 07, 2007
Friday, November 02, 2007
Software Professionalism - Autos (Automated Tests) make for sustainable, realistic software
Statement: A
We, responsible software development professionals, MUST build sustainable, realistic software.
I've intentionally chosen not to use the word 'working' in that statement. 'Working' seems to be a word that is easily perverted to alternate definitions. It's not enough to build software that works once! It's not enough to build software that can be judged as working after several weeks of manual testing! Sustainable, and realistic might be better adjectives. I've never been on a project where there was no expectation of being able to enhance the software that was initially delivered, or that the software being delivered not be something which serve the needs of the person it was written for (though that does get confused easily it seems).
Statement: B
In order for software to be enhance-able (in any reasonable time frames, with a high truck-number) a powerful suite a autos (automated/executable tests) is required.
The more diverse the types of autos (unit/integration/acceptance/etc), the better. The more realistic paths exercised, the better. The faster that auto suite can run, the better. The less autos you have, the more risky it is to make changes. The less autos you have, the harder it is to introduce new developers.
Statement: If (A and B) then C
Being a software professional requires that you build autos with your software. Doing anything less is unprofessional.
I am guilty of not building autos in the past. But I hope I have learned from my mistakes. As responsible developers, we absolutely must make it a regular part of development to build autos for our companies, our clients, and each other. It is the professional thing to do.
We, responsible software development professionals, MUST build sustainable, realistic software.
I've intentionally chosen not to use the word 'working' in that statement. 'Working' seems to be a word that is easily perverted to alternate definitions. It's not enough to build software that works once! It's not enough to build software that can be judged as working after several weeks of manual testing! Sustainable, and realistic might be better adjectives. I've never been on a project where there was no expectation of being able to enhance the software that was initially delivered, or that the software being delivered not be something which serve the needs of the person it was written for (though that does get confused easily it seems).
Statement: B
In order for software to be enhance-able (in any reasonable time frames, with a high truck-number) a powerful suite a autos (automated/executable tests) is required.
The more diverse the types of autos (unit/integration/acceptance/etc), the better. The more realistic paths exercised, the better. The faster that auto suite can run, the better. The less autos you have, the more risky it is to make changes. The less autos you have, the harder it is to introduce new developers.
Statement: If (A and B) then C
Being a software professional requires that you build autos with your software. Doing anything less is unprofessional.
I am guilty of not building autos in the past. But I hope I have learned from my mistakes. As responsible developers, we absolutely must make it a regular part of development to build autos for our companies, our clients, and each other. It is the professional thing to do.
Subscribe to:
Posts (Atom)