Blogs
Explaining the other work we do
Submitted by Karen N. Johnson on Mon, 08/02/2010 - 15:54.I had a technical issue I needed to research for a client. Nothing surprising, I research different bits of information frequently. At the end of my research I realized I wanted to explain what I'd done, I wanted to clarify and present what avenues I had pursued, what information I'd learned, what issues remained and what possible other solutions we might look into. I realized I wanted to share these bits of information with the project team so I set out to write an email.
Agile Performance Testing in Software Test & Performance
Submitted by Alexander Podelko on Wed, 20/01/2010 - 22:32. agile | non-functional testing | performance testing | performance testing patterns | performance testing toolsA magazine version of my Agile Performance Testing article was published in the November 2009 issue of Software Test & Performance.
I explained what this article is about in my earlier post
I explained what this article is about in my earlier post
A Performance Engineering Story with Database Monitoring
Submitted by Alexander Podelko on Wed, 20/01/2010 - 21:38. databases & SQL | performance testingI put my CMG'09 presenatation A Performance Engineering Story with Database Monitoring on my site.
By the way, CMG'10 call for papers and workshops are available, next year it would be a separate subject area for Load Testing.
By the way, CMG'10 call for papers and workshops are available, next year it would be a separate subject area for Load Testing.
More Sharks and Delaying Critical Mass
Submitted by Antony Marcano on Tue, 19/01/2010 - 16:37. agile | project managementIn a previous post I talked about Critical Mass of software. I showed how an ever-increasing cost of change resulted in it becoming more economical to completely rewrite the system than to enhance and maintain the original.
I explained how this could be avoided by using practices that sustain a consistent and flat cost of change. I also mentioned that you could defer reaching critical mass. Some teams find it difficult to get the time to do this because "the business" always has "more important" or "higher-value" things on their backlog.
I explained how this could be avoided by using practices that sustain a consistent and flat cost of change. I also mentioned that you could defer reaching critical mass. Some teams find it difficult to get the time to do this because "the business" always has "more important" or "higher-value" things on their backlog.
Sharks, Debts, Critical Mass and other reasons to Sustain Quality
Submitted by Antony Marcano on Mon, 18/01/2010 - 14:43. agile | development methodology | extreme programming (XP) | project managementA while back I tweeted about critical mass of software:
Critical Mass of Code - past which the changeability of the code is infeasible, requiring that it be completely rewritten.
An elaboration of this might be:
Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.
This graph illustrates a hypothetical project where the cost of change increases over time (the shape of which reminds me of a thresher shark):
De-smelling by refactor or rewrite: some thoughts
Submitted by Erik Petersen on Sun, 17/01/2010 - 02:14. design & developmentIs there a tipping point when rewriting code should be favored over refactoring ? It is often hard to decide. There are some important factors that can help. Code smells cluster, whether as bugs that are detected, or potential failures lurking in immature code that may break during future updates or maintenance. Steve McConnell wrote (in “Rapid Development”) that “Error prone modules tend to be more complex than other modules in the system, less structured and unusually large. They often were developed under excessive schedule pressure and were not fully tested”. He also quotes indicative studies that these modules are much more expensive to develop. Steve’s metric is 10 defect per 1000 lines of code to mark a module for further work. If it appears to be an error prone module, he advises rewriting it. Other indicators are large concentrations of bugs, large number of checkins, or large amounts of fix time spent in comparison to similar modules. While error-prone modules are typical in traditional development, agile practices like well executed TDD should minimize them. High cyclomatic complexity of code is also a good indicator of the need for simplification.
The hard thing is determining the tipping point between refactor and rebuild. The easy thing is that because of clustering, there is often a lot of low hanging fruit, and focused effort on a small portion of the code should have a massive impact on the code quality.
For more on bug clusters and other productivity ideas, see my Google tech talk “Building Software Smarter”, http://www.tinyurl.com/80-20-rules
Here be dragons
Submitted by Karen N. Johnson on Thu, 14/01/2010 - 17:34.I like maps. I wasn’t sure why maps appealed to me until it dawned on me one day that maps are a form of data visualization. The phrase “here be dragons” was used by mapmakers many years ago in reference to uncharted or unexplored areas. I like the phrase. Maps were marked with dragons and in some cases, other animals were drawn to signify danger or unknown, uncharted territories. I find the concept and the phrase kind of cool in a geeky sort of way. You can read more about this old mapmaker’s phrase here.
I also like SQL. I like being able to access a database and spend time with data. I teach a couple of different SQL classes and one thing I’ve found repeatedly has been people’s intimidation by having to write a join in SQL. It’s amazing how far people will go to avoid the dreaded join – it’s a bit like “here be dragons” - a territory marked with fear and uncertainty.
I also like SQL. I like being able to access a database and spend time with data. I teach a couple of different SQL classes and one thing I’ve found repeatedly has been people’s intimidation by having to write a join in SQL. It’s amazing how far people will go to avoid the dreaded join – it’s a bit like “here be dragons” - a territory marked with fear and uncertainty.
» 2 comments | read more
experiencing a bug as an end user
Submitted by Karen N. Johnson on Wed, 16/12/2009 - 06:02.It’s been a long time since a software bug agitated me - one that I was hit with as a user not a tester. But I've had one I've been dealing with this past week.
In some ways it’s been interesting to feel like a user. To get whacked unexpectedly with a software bug that impacted my day and took time to resolve. Mostly it’s left me agitated and thinking less of the company.
Blackberry released an upgrade to their software and I took the release. I didn't notice straightaway that the update stomped out my Google sync settings. Wiped out Google sync entirely, I had to reinstall. And impacted my Gmail, calendar and maps.
In some ways it’s been interesting to feel like a user. To get whacked unexpectedly with a software bug that impacted my day and took time to resolve. Mostly it’s left me agitated and thinking less of the company.
Blackberry released an upgrade to their software and I took the release. I didn't notice straightaway that the update stomped out my Google sync settings. Wiped out Google sync entirely, I had to reinstall. And impacted my Gmail, calendar and maps.
