Big Steps to Code Integrity
Typemock is making big steps towards its goal of code integrity.
Code integrity is what we consider the new paradigm of writing software. Moving the responsibility of code-correctness back to the developers. It is too easy to get sloppy and to leave it to the QA to find our bugs, thus developing without integrity and leading to waste in time and money. When developing with integrity, we are all responsible to make sure the code does what was intended to do.
We can reach to higher levels of code integrity, with automating unit tests, code reviews and management for excellence. We are helping teams do this by allowing developers to unit test their code, whatever design or technology they choose. Our new tool Racer allows validating Parallel Computing problems. This is a great step towards making our profession an engineering one, that we can be proud of.
1 Comment to “Big Steps to Code Integrity”
Recent Posts
- Top 5 questions to ask when checking references
- Unacceptable: Unit testing will take 20 years to catch on
- The 4 reasons why we DIDN’T choose Oslo
- Typemock Academy Launch
- The First Rule to Software Craftsmanship
Categories
- .NET Tests
- Agile
- Code Integrity
- Community
- Debugging
- Fun
- Management for Geeks
- Marketing
- Product
- Release
- Reviews
- SharePoint
- TDD
- Time Management
- Uncategorized
- Unit Tests
Archives
- August 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
A wise Quality Assurance Manager once told me that if you look carefully at what “QA” stands for: it’s to “assure” the quality of the product, not to build in quality. It all comes back to the developer to build in quality, security, scalability, etc. etc. QA’s job is to verify that it is meeting the requirements. At http://www.codeintegritysolutions.com, we see a number of organizations who are working hard to build quality into the software development process, not after the fact. Better design tools, static analysis and building of test frameworks are a great way for developers to build in quality. It’s good engineering and better/cheaper/faster in the long run.