Insomnia Consulting Still searching for an interesting slogan

PittJUG 3/30 - About JDK7

• http://bit.ly/ay4uMO
• http://tech.puredanger.com/java7/

http://openjdk.java.net/projects/jdk7/features/
 Still no JSR for JDK 7

I just had a couple days of training and am so excited about the experience I wanted to share it here.
 
I'm not a rep for the company, I'm just posting this because I enjoyed it so much I wanted to share it. 
 
The training was presented in a "games" format.  The first class was an 8 hour class on business finance & accounting.  The second day was 4 hours on "teamwork & collaboration"
 

I've had a lot to Tweet about lately regarding the service that Pittsburgh Area Transit (PAT) offers.  Mostly bad, and a little good. 
 

I've just recently had to switch back to doing development on a Windows box, after a couple years of using a Mac (and still using a Mac for my personal work). 
 
There are many things that frustrate me.  In particular, the Console (cmd.exe), even with with Cygwin installed, is horrible.  In search of a better terminal, I came across Console2 http://bit.ly/bKPvqq .
 

After reading this article in Harvard Business Review (http://hbr.org/2010/01/success-gets-into-your-head-and-changes-it/ar/1) and this one in Wired (http://www.wired.com/magazine/2009/12/fail_accept_defeat/all/1) I was once again reminded of all the smart people who have advocated doing retrospectives to improve team performance.
This blog by Ty Kiisel sums it up nicely  http://blogs.attask.com/blog/strategic-project-management/0/0/the-projec....

Testing is what we do to make sure our decisions are sound.  Peter Drucker said that every decision should have a test to make sure it was a good decision (The Essential Drucker; Drucker, Peter, 2001, p. 250)..  Sounds like Test Driven Development.. but I don't want to digress.
 

Many core concepts related to software development performance have been addressed while writing about speed of delivery.  Hopefully, it is becoming clear that speed of delivery is a localized effect and can't be generalized to all teams for all products.  This final entry on delivery speed addresses the responsibility that engineers and product managers have for identifying how to best choose an architecture that allows the team to optimize speed of delivery and make good decisions about when to evaluate architectural changes to prevent a prolonged degradation of delivery perform

There are two key points that should be made in regards to "Speeding Delivery". 1. Speed is a function of how much work a team can accomplish in a fixed period of time. 2. Delivery presumes that the ideas are already formulated.

I just read an excellent article: "Trade-offs between Productivity and Quality in Selecting Software Development Practices" by McCormack, Kemerer, Cusumano, and Crandall (http://bit.ly/3IqF8d).

This article, like many that explore software productivity measurements, has some KLOC metrics littered throughout the article (along with some other engineering metrics) to evaluate programmer output. Most metrics, that can be applied to software development, are somewhat superficial. They can be gamed and they're usually only valid in like development efforts. However, I'd like to discuss in a bit more detail why KLOC-type is as good as anything if we're talking about THAT kind of measurement. Then, let's look at ROI and find out where it can help and hurt.

The OnProductManagement blog peaked my interest with this entry (http://bit.ly/fItET). In the blog, Alan discusses the mandates that most VPs of Engineering are faced with. The point of the article is to look for a similar mandate for Product Management, but I'd like to focus on the engineering mandates. The first of these is "Increase Speed of Delivery".