During a recent conversation, a service provider equated our product to a "bullet." The implication is that 6th Sense can arm customers with information that can injure a relationship.
I was shocked.
I've heard our product described many ways, yet this was a first. I challenged his charge, and he explained that some customers simply don't understand how to use the data and will misinterpret.
Sadly service providers are driven by risk-mitigation -- not how to build a stronger long-term relationship with their customers. I discussed the importance of the truth in a previous post. Service providers need to treat their customer relationships like personal relationships, and trust is the cornerstone of all successful relationships.
I don't need you to be evil
In an early customer meeting, a manager declared, "I don't need this product to be evil." If a customer is searching for a reason to end a relationship, they will find it. They don't need 6th Sense. They don't need any other tool to do this. And the bigger question is "why is the customer unhappy?"
Service providers need to embrace transparency -- not simply market it. Transparency is scary but will ultimately lead to stronger relationships with customers. If a customer is unhappy, locate the source and eliminate it. If a customer is simply impossible to please or "evil", consider having a candid discussion or revisit whether the customer is the kind of customer you want.
Regardless, don't shoot us -- we're just reporting the truth.
A few months ago I sat down with Michael Nygard (
http://www.michaelnygard.com ), author of the Jolt Award winning book
Release It!. We discussed what developers should be aware of in the next year and the number one career tip he's like to pass onto you.
This is a Neal Ford quote that sums up so many software shops. We know we should be writing automated tests. We know that continuous integration is something we should run and keep clean. Peer code reviews? Uninterrupted work time? Check and check.
We know many, many practices we should use everyday. But we get caught up in the urgency of the moment. We fall into crisis management. Bug driven development. "Shut up and code!" becomes the unwritten rule of the shop. No one says that writing automated tests is bad, but everyone is constantly driven to add new features instead.
We confuse activity with progress.
Just because you're working hard doesn't mean you're heading in the right direction. It only means you're sweating. It takes a bit of time to step back and ensure you're headed in the right direction.
It's like driving to a meeting. It's an important meeting and you don't want to be late, so you drive as fast as you can without getting a ticket. You're running questionable yellow lights. Then at some point your spouse points out that the car is nearly out of gas and you've still got a long way to drive. Your response?
"We can't stop for gas. We're already running late."
It sounds dumb when we say it that way, doesn't it? Running out of gas takes far more time than re-fueling ever would. But that's how we develop software. We continue our mad dash and long hours until the team or project runs out of gas... and that's one of the big reasons 75% of all software projects fail.
Take the time to stop for gas. And even directions... (when's the last time you read a software book?). Call it stopping for gas or sharpening the axe... but do it! Tools like 6th Sense can be used to pick out practices for your team. So can a process coach, or a good talk at a conference.
If you focus too much on driving, you might not make it to your destination at all. Pull over and recharge.
Are you working on your Jack Nicholson? I hear far too many comments like this. Apparently others do as well.
"What will my customer think if they realize we only spend 50% of our day developing and spend the rest in email and other tools?" -- a common question from service providers
"You're better than average," I typically respond.
In the past 30 days here's the breakdown of tool usage in our development community:
- Web Browsers: 47%
- IDE/Editors: 16%
- Email: 14%
- Office: 9%
- IM: 6%
- ...rest...
So if your developers are spending a majority of their time outside of a development environment, they are normal.
True Transparency
True transparency is a scary concept especially when it's contrary to the status quo. Right now customers have very little visibility into the software development process. They've been living with "trust us -- it's 75% complete" for a very long time. Sometimes this is correct -- some times it is grossly inaccurate. Regardless, it is the way things are often done.
Maybe I'm naive, but I feel that customers / business folks can handle the truth. Of course, the truth needs to be accompanied with explanations and examples. I also believe that the truth could improve predictability in projects and vastly improve relationships.
Concern about customers learning the true is simply due to the lack of education. A key part of education is having the facts and metrics to back up assertions. Developers ( and development teams ) complain about scope creep all the time. It's definitely the top complaint I hear. Do the development teams ever graphically illustrate the time waste in scope creep? Do they have spreadsheets with the time ( and $$ ) lost? Sadly, they rarely do. Most would rather simply complain at the water cooler.
The Truth Hurts
I searched online on why it's hard to tell the truth and found a nice thread on it. However, in software development the truth doesn't necessarily hurt anyone, but I agree that folks often don't want to hear it. They want their software 2 weeks early, under-budget and bug-free.
Alas, this is usually unrealistic, so it's better to start telling the truth to appropriately set expectations which will lead to far less disappointment for everyone.
Data where you want it
I'm pleased to post a new video demonstrating how to mash-up 6th Sense data into Google Spreadsheets. Internally, we are proud Google Apps customers and have moved many of our spreadsheets online. We're excited by the opportunities presented by marrying our development data with our traditional spreadsheets.
This is just the first example of many to come on how we can bring our data to the places you want and need it. We hope you enjoy this capability.
Click Here for Video
After landing in SFO on Friday, I received word via an alumni email blast that Dr. Randy Pausch passed away at age 47.
For those who don't know Dr. Pausch's story or have not seen his amazing Last Lecture yet, I encourage you to take an hour out of your busy life to view it. I did not personally know or have Dr. Pausch as a professor during my time at CMU. He returned to the university the same year I left. However, I felt a kinship with him given our alumni connection and passion for CMU.
Following Your Dream
A reoccurring theme in his lecture ( and book ) is following your dreams. "If you lead your life the right way, the karma will take care of itself," Pausch said. "The dreams will come to you." And while there is nothing completely new to his message, the style and vigor in which he presents it -- and lives it -- is a great reminder for all of us.
6th Sense Analytics is my dream. For the record to all the big-brother haters out there: spying on people has never been in any of my dreams. I wanted to take a brief moment to thank our customers, investors and employees for helping make my dream a reality. While I'm certainly not disillusioned into thinking that using 6th Sense is life-changing for everyone, I do hope that interacting with us has a small positive impact on people's lives.
- Todd Olson, E'97
In historic news, Borland announced the "first business intelligence (BI) application for application-lifecycle management (ALM)." We applaud Borland's efforts in this area. We absolutely agree with the direction and philosophy behind the change. However, they were a little off in their counting of solutions.
Cast has been in business for years selling software measurement and metrics solutions. SourceIQ is a more recent company, but also beat Borland to market. And of course we've been publicly available for almost 3 years.
The concept of metrics
We've learned from years of speaking with software development organizations that the concept of metrics / measurement is important. However, evolving an organization from intuition-based to fact-based is a huge transition. It certainly takes more than simply a software product to make this transformation.
Despite my tongue-and-cheek introduction, I'm truly excited that Borland is increasing the spotlight on software metrics. Their general approach is very familiar and in our mind the right way to solve the problem. And their marketing machine will bring a lot of visibility to the challenges and appropriate solution. However, I do worry about their ability to execute on the vision of this product.
OpenALM sounds promising, but it's a dream. Go to the website. There are vision statements and manifestos -- no API specifications or supported tool lists. We support over 40 ALM tools and each of them requires knowledge of a completely different API and even technology. In some cases, we've resorted to screen-scraping data from web pages. Borland has an even greater challenge of supporting their own ALM platform while dealing with their competitors' offerings. In our experience each customer has a healthy combination of best-of-breed tools.
Customers don't care about openness. They care about the insights they can derive by harvesting the data out of the tools they chose.
Don't Believe Everything You Read
So don't be deceived by marketing collateral. I'd encourage companies seriously interested in transforming their business to evaluate all the solutions in the marketplace and factor in experience and focus to their decision-making.
6th Sense tooling is in a sensitive space. Allowing others to see what you're doing during the day can make you feel vulnerable. Especially if you don't trust your management. (If that's the case, why are you still there? But that's another post about co-dependency and enabling personalities....)
We've worked very hard to train our customers on the proper use of metrics. Measuring not monitoring. Tracking progress. Burnup charts. Estimation accuracy numbers. Moving past developer optimism ("I know I can make this work!") and to a measure of what's actually done.
Read More
Not enough data
When we started, we only captured data from popular development tools like Microsoft Visual Studio and Eclipse. After about six months of market feedback, it became clear that we needed more. Developers spent a large amount of their time outside of development environments, and our customers felt that this void reduced the ability to take action on the data.
So we built web browser sensors and an operating system level sensor to ensure that we caught 100% of computer time. Problem solved.
Too much data
100% of computer time including 100% of web browsing time just amplified "big brother" objections. Many developers raised violent opposition to the product because it captures all time -- including personal activities. We already had the ability to obfuscate URLs, but it was limited. And there was no way to turn data collection off completely.
A fundamental rule we've lived by is that relying on human interaction is bad.
We didn't want to be plagued by the same challenges as traditional project management solutions. Our goal has always been to get out of the way and reliably collect data. We had many discussions on how to empower developers without becoming a burden.
Inspiring use case: The Independent Contractor
During the time we were designing this new feature area we contracted an individual to help us with a sensor. Of course, he installed our product. I could review his data and get a sense of where the time was being spent -- and even compare it to the bill. One constant challenge was dealing with his "windows media player time." Every night around 7PM, he played music, watched movies. I didn't want to see this. I didn't want to create rules to filter it out. I didn't want to customize reports to exclude it. I simply did not want it at all.
Our Solution
First, despite countless debates the general feeling is that there are times that people want to be completely private. There are instances where it is well known that all the activities on the computer have nothing to do with business. A good example is Private Browsing in Safari. In this case, having the ability to turn "off" data collection is important. The challenge is that folks can forget to turn it back on. Folks will forget to turn it back on. This of course is unacceptable. Therefore, we settled on defaulting the private mode to one hour ( typical lunch break ) and supporting up to four hours ( typical evening ) off.
The other primary use case involves removing known activities that are personal -- e.g. windows media player. This called for a light rules engine to exclude data based on a pattern. Of course, this requires us to have the mechanism to review the data to see which would even apply. Hence, Manual mode was born. Desktops in manual mode just collect data for review. Data can be excluded individually, or rules can be created to bulk exclude.
Once an individual is confident in the data collected and has established appropriate rules, he can switch to automatic mode which submits all non-excluded data every 10 minutes.
Design is about compromise
So we didn't implement a simple "off" button, but we feel we captured the intent of the request and addressed real user issues with this feature set while maintaining our key principles.
To see more of this new feature check out the video here.
