The Personal Software Process (PSP) is one of the historical drivers to HackyStat and the 6th Sense Analytics model. I remember when PSP was first introduced in the mid 1990's. At that time there was a tremendous amount of concern surrounding the use of the detailed data that each engineer was collecting. Not so much at the individual level, since the vast majority of developers who underwent PSP training enthusiastically supported the technique and were amazed by the insights that this level of performance data could provide. Those most concerned were the methodologists and pundits of software managers and leaders.
Traditional wisdom at the time was that command-driven managers couldn't handle the truth of the data and would somehow misuse it when judging, rewarding and leading the team. In fact, early PSP trainers were required to hide individual data from leaders so that they couldn't discern individual characteristics. As with many things, I believe this was a gross overreaction connected to a lack of faith in the maturity and skill of software management. While there are always a few "Bad Apples" in any profession, I firmly believe that most software managers are competent, thoughtful and caring leaders. However, they are in the business of leading teams toward delivering business value and making wise trade-offs between speed, quality, content and people.
From a PSP perspective, I’m unaware of a single, documented instance where having finely grained data to understand team performance and capabilities has led to a project failure. I would hazard a guess that data is not a project failure attribute, whereas a lack of it is.
One of the factors that make software leadership so challenging is the lack of deep insight into actual team operation. I liken it to driving a car at night without my glasses and turning off the lights. Yes, it's that dangerous! Given this lack of insight, I think leaders are making the very best decisions they can, but it is not surprising that over 60% of software projects are still failing.
Instead of worrying about what negative things managers, leaders, project managers, and executives might do with performance metrics data, I would rather focus on the POSITIVE possibilities. Here are just a few ideas for the pessimistic:
- You can actually estimate work based on productive Active Time instead of guessing.
- You can constructively evaluate the true performance levels of your team members and make more effective work assignments.
- You can evaluate Flow Time and modify organizational dynamics to improve focus (Flow Time) and actually see measured effects of the changes.
- Team members can learn where and how to improve their development performance
Insights like these can do nothing but increase the effectiveness of software leaders and their team. Turning well intentioned, but data deprived managers into powerful and insightful coaches of high performance teams.
The Deming quote applies very well here - "In God we Trust, All Others Bring Data". Data is nothing to be afraid of and will lead you towards much better results. All it takes is a little data, insight and perhaps courage.
As with anything in life, metrics analysis can have a light and a dark side. I inevitably think of Star Wars and the constant struggle between the two sides of the force—the dark and light. Depending on your perspective and experience, analyzing your teams’ data can provide tremendous insight and competitive advantage. However, if you do not show wisdom, care, and understanding, this analysis can quickly be misused and become highly disruptive.
I was recently teaching a course on test case construction in which we were exploring a section on test metrics to measure testing progress and product quality. One of the slides contained a set of example metrics. Here’s one that caught the attention of the class:
Metric - Measure test team efficiency by calculating the number of testing hours per defect detected.
The class immediately went to the "Dark Side" and reacted viscerally to the example. Discussions churned around different perspectives. For example:
- From a development perspective, this measure did nothing to evaluate the quality of the development team deliverables—the code. It simply tries to reward fewer bugs, but didn’t speak to the nature of them, including priority, severity, pervasiveness, or complexity. Nor did it speak to bugs that ultimately reached the customer.
- From a testing perspective, the metric revealed nothing about the quality of the testing team’s efforts towards detailed planning, broader strategy, types of testing being applied, and project schedule support. It also does not consider the quality of the bugs found nor the maturity level of the product as it is released.
- From a management perspective, it is not clear what the measurement was driving towards or what behavior the metric was trying to encourage. This metric might be valid. However, more likely it would drive negative behavior within both teams as they try to positively support the metric.
This is clearly an example of a poor metric. One that illustrates why many software engineers react poorly to requests for more information on their working habits and project progress. It also alludes to the fact that most good metrics require deeper probing, drive additional questions and rarely lead to a simplistic response.
Instead of looking at software development data with this approach, our analytics should lead you in another direction. No, you are not "Big Brother" or Darth Vader or their victim. Instead, you are an experienced software developer or leader who understands that detailed data can provide tremendous insight and lead towards carefully crafted adjustments in individual and team performance—which can truly be the difference in project success or failure!
What's the number one challenge applications developers will face over the next five years? According to analysts at Gartner, it's the same one the businesses acquiring those applications will face: integration.
"In the past, developers didn't have to make [applications] work together because we had people doing the integration," Roy Schulte, VP and distinguished analyst at Gartner Research, said during a session at the most recent Gartner ITxpo. "Now we've got applications talking to applications all over the place. And so it's something everybody has to do all the time."
"I cannot understand why this is not talked about more than it is," Schulte added.
He might not be hearing it, but developers are certainly talking about this app integration "challenge." Or at least they're thinking about it. Need evidence? How about Gartner's own stats, which show that 75 percent of all new applications being developed today use some kind of integration technology. Schulte pointed out that we can expect to see "integration logic" becoming another facet of the best-practices definition of applications, alongside presentation logic, business logic, and data logic. That's a huge change in application design. Need more evidence that developers and IT execs are thinking about application integration? Schulte's session was packed.
What developer working in the mainstream today could not know that the app he/she is building is going to be touched by other software? Even the schools are finally abandoning the old-style monolithic development styles, training their students instead for the fast-approaching service-oriented and event-driven world.
But Gartner does point out one worrying fact that may not be getting enough attention from the developer community: When you change the architecture of applications, you also have to change the middleware infrastructure running under those applications. "You can't do SOA using the kind of middleware you used for the past 20 years to build distributed applications," Schulte said. "Object request brokers, TP monitors, application servers, RPCs, sockets—-they're all great but they're not good for SOA and event-driven architecture. Therefore, you will have to change your underlying software infrastructure to use enterprise service buses."
The good news--or at least interesting news--is that stand-alone ESB products probably aren't long for this world. According to Schulte, it won't be long before most enterprises gain ESB functionality through other products that include them. The upcoming Windows Vista operating system, for example, includes the Windows Communication Foundation (WCF) architecture. "You'll buy an integration suite from Tibco, WebMethods, IBM, or Oracle with an ESB in it," Schulte said. "You'll be using an ESB because it really is the right infrastructure for SOA and event-driven architectures, but you may not be choosing it."
You know it’s bad when a consultant chucks in the towel! Pamela Slim, a consultant to enterprise-level management of 10 years� standing, is giving up because she’s tired of banging her head against the wall trying to creatively present stupid ideas to employees, that create an atmosphere of resentment and unwanted competition.
Pamela has penned an excellent 10-point open letter to CEOs, COOs, CIOs and CFOs, outlining a plan of action that centers heavily on dumping the PowerPoint and getting to know, and really value, employees. It also serves as a call to stop using buzzwords and meaningless jargon like “our employees are our most valuable asset.”
You can read the letter here, but Pamela raises some points that apply to the world of software development, and hit on some of the issues 6th Sense Analytics is trying to resolve.
Read More
It’s easy to criticize or to be negative — especially when it comes to new ideas and concepts. It’s happened throughout our history. The concept that the Earth travels around the Sun, not vice versa, developed by Copernicus was revolutionary, quite correct and completely rejected by the Church at the time.
Remember when Java and “write once run anywhere” was devised? Well� OK “write once and run anywhere” is a little questionable, but few people got the idea or understood Java in the early days, and most expected Java would wither away.
Kathy Sierra notes there�s one real reason that people diss new things: it�s because the thing in question challenges beliefs or ideas they have invested in heavily. They could have invested time or money, or staked their reputation.
“They’ll diss things because embracing those things might force them to re-examine thoughts and assumptions they care about, or because those things represent a change they don’t want to make,” Kathy says. She goes on, that the less someone knows about a subject, the more passionate the dissing.
The changes we are in the midst of today are once again challenging some old ways of working. Turn-around times in software development projects are speeding up, development teams are becoming distributed and harder to manage, and there is a greater focus on quality and return on investment by the business.
These require a more flexible and predictive way of running projects. It’s no longer good enough to steer projects using gut instinct or to tear everything down and start the next project from scratch, without carrying over best practices and lessons learned from the previous effort. There’s too much at stake in terms of saving money and reducing your exposure to risk.
Yet people can be slow to embrace the changes these challenges demand. Either, people think everything will be OK because they’ve done this kind of thing before, or they get religion about the tools they already have.
On the first point, things could well be OK, but surely the question becomes: how can you make things even better? On the latter, it’s fine to use existing tools - we encourage it - but these tools will probably fail to provide an accurate or impartial view of the entire development ecosystem, because they are tied to a single vendor’s stack.
Facts can be uncomfortable things to face but facing them is the first step on the road towards self-improvement. That’s why 6th Sense Analytics’ tools give people the facts they need to run software projects under today’s changing requirements. We also give people the information in real-time, while also providing a complete view across the entire application development stack.
Who can argue with that?
6th Sense Analytics metrics
Pop quiz: What's the difference between a "nice to have" and a "need to have?" We've drawn up a list of three, seemingly unconnected, items you might rate as either nice to have or need to have. See which you think is the odd one out:
- Travel insurance
- Dell PowerEdge, duel-core, 4U rack-mounted server
- A Porsche 911
Obviously, the Porsche is the nice to have. You don't actually need a Porsche to get from A to B. But travel insurance and Intel servers? Well, travel insurance and a well spec'd Intel server qualify as need to haves. Why? Because, while they may seem like superfluous expenditures at the time of paying -- paying, that is, either for your holidays or when you are deciding whether to pick a cheaper server -- when you are caught in a crunch -- be it illness on holiday or scads of new users suddenly hitting your web site for a marketing offer -- their value, and the wisdom of your choice, speaks volumes.
Both will make your life easier, save you money in the short term, and -- in the case of the server -- help your company make money, as new business can hit the server and not get turned away by Error 404. Nice to have just became need to have.
In a similar vein, you have 6th Sense. We also help you save time and make money by, quite simply, by ensuring your software projects are delivered on time. We do that by letting you know where your project is, where your developers spend their time, and how your software developers are absorbing other technology and business decisions being made on a daily basis.
Read More
RESEARCH TRIANGLE PARK, NC, DATE, 2006 � 6th Sense Analytics, delivering real time insight into the life of software projects, has been named a “Cool Vendor” in the March 20, 2006, “Cool Vendors in Application Development, 2006″ report published by Jim Duggan, et al of Gartner, Inc.
The vendors highlighted in this year�s report are striving to make software development more measurable, repeatable and easily managed. They are part of a transformation in approach within IT. Managed processes are being created that can be re-used in successive projects. Persistent processes make instrumentation both desirable and necessary.
“6th Sense Analytics helps steer distributed software development projects towards success,” said 6th Sense chief executive officer Greg Burnell. “Business and development teams have traditionally relied on bulky reporting tools or gut feeling to plan and deliver software projects. 6th Sense provides up-to-the minute, fact-based insight empowering teams to take the necessary steps to keep software projects on track and establish repeatable processes.”
6th Sense Analytics uses an independent, open, web-services architecture to collect and analyze project metrics. A suite of community-supported software sensors integrates with leading tools, delivering a complete picture of the development lifecycle - not just from a single vendors’ perspective. 6th Sense Analytics’ AJAX-based reporting system presents metrics using online charts that can be customized to meet individual business and IT users’ needs.
About Gartner’s Cool Vendors Selection Process
Gartner’s listing does not constitute an exhaustive list of vendors in any given technology area, but rather is designed to highlight interesting, new and innovative vendors, products and services. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness of a particular purpose.
Gartner defines a cool vendor as a company that offers technologies or solutions that are: Innovative, enable users to do things they couldn’t do before; Impactful, have, or will have, business impact (not just technology for the sake of technology); Intriguing, have caught Gartner’s interest or curiosity in approximately the past six months.
About 6th Sense Analytics
6th Sense Analytics is for everyone with a stake in software development. Founded in 2004 by a team of experienced developers, 6th Sense Analytics uses an open and independent architecture that provides visibility into the status of distributed software projects. We integrate with the leading IDE and editors such as Visual Studio and Emacs; source control management systems including ClearCase and Subversion; and change request management systems such as ClearQuest and Bugzilla. 6th Sense Analytics, based in Research Triangle Park, North Carolina, is already helping major systems integrators, independent software vendors and Fortune 500 companies steer distributed software projects towards success.
