Wednesday, May 23, 2012

The Popularity Contest


Having trouble viewing this email? View it in your browser.

Advanced Decisions

The Popularity Contest


In an effort to keep our subscribers happy we've decided to allow segmentation of newsletters.


This means you can now choose if you want to receive






Click one of the links above to segment yourself. (Note: the links will direct you to our website in addition to recording your newsletter preference.)


We'll provide this option in all newsletters from now on, so you can resubscribe or unsubscribe whenever you please. Thanks.


-Judi and Gary


Back To Top Header



Know someone who might be interested in this email? Click here to forward it.


Not interested anymore? Unsubscribe.




Tuesday, May 15, 2012

Process Fanatics are Necessary

Most development executives want to improve their product development processes and achieve

  • Faster time to market

  • Higher quality products

  • Products that resonate better with users

And though all of these can be achieved with improvements to software development processes, they rarely seem to get done.

One recurring reason for not achieving these is the absence, in many software organizations, of a dedicated SQA (Software Quality Assurance) employee or department. Too often, management loosely assigns the responsibility to an already-overworked employee, which guarantees that SQA will crash and burn.

It's too bad that SQA is given such mediocre attention, because it's often the key factor in achieving better products that release faster.

Do you agree? Is SQA often the secret to better products?


Monday, May 7, 2012

Who's Testing Your Code?

I often talk with software executives about the structure of their software development teams.

Some of their common questions are

  • Should developers interact with users? (Yes)

  • Can developers write their own requirements? (Sometimes)

  • Can developers test their own code? (No!)

I believe strongly in the last question's answer. There needs to be someone else besides the developer to test the product.

Yes, developers need to test code to make sure it’s working, but the test team has a completely different mentality and skill set. They should be trying to see where the software breaks, because if they don’t find those spots, a user will.

Who tests your code? Are they doing a good job at it? Let me know.