A common question in the open source arena is “Would you buy a car with the hood welded shut?”. The answer is always an emotional “No!” But most teams have crawled into a box and welded the lid closed behind themselves. And it’s tolerated.
Bob Young, RedHat’s former CEO, published an article in 2000 (Open Source is Here to Stay ). Much of the article applies directly to the team-wide metrics 6th Sense gathers. And I think, just like RedHat and Linux really moved open source into the business mainstream, 6th Sense will have just as large an impact on the software industry.
Let me quote Bob’s article:
The best analogy that illustrates this benefit is with the way we buy cars. Just ask the question, “Would you buy a car with the hood welded shut?” and we all answer an emphatic “No.” So ask the follow-up question, “What do you know about modern internal-combustion engines?” and the answer for most of us is, “Not much.”
We demand the ability to open the hood of our cars because it gives us, the consumer, control over the product we’ve bought and takes it away from the vendor. We can take the car back to the dealer; if he does a good job, doesn’t overcharge us and adds the features we need, we may keep taking it back to that dealer. But if he overcharges us, won’t fix the problem we are having or refuses to install that musical horn we always wanted—well, there are 10,000 other car-repair companies that would be happy to have our business.
Today the consumer is the management chain and the engine builders are the teams that lock out their managers. Maybe they don’t trust their managers. Maybe they think that withholding information makes them more powerful. All it really does is breed mistrust and make it much harder for managers and technical leads to do their jobs.
When we hide information from the management chain who signs our paychecks, why are we surprised that they outsource our jobs?
Are our managers software gurus? Usually not. Just like the internal combustion engine experts example… managers with software expertise are uncommon. Does that give us the right to deny them access? No more than it would give Ford the right to weld our car hoods closed because we don’t know to build an engine.
Will your manager abuse this information? Not unless they want to their team to quit. To put it another way, when’s the last time you popped the hood of your car and started pulling wires? Hopefully never. It would be a stupid thing to do. How many stupid managers are going to start messing with a teams’ internals? If Dilbert is to believed, all managers are dumb. But I suspect the truth is that there a lot of smart people out there doing the best job they can. Let’s make sure they have access to everything they need to do their jobs.
6th Sense gathers information from both the desktop and the server (see our list of sensors). Does that make it a “big brother” tool? No more than having a hood latch makes you a car vandal. It’s just a tool.
Is it a tool that makes you comfortable? Maybe. Maybe not. Is it a tool that makes more information available? Absolutely. Is this information we’ve traditionally made available? No, it’s a new way of thinking about productivity and product management.
Make the information available. Open the hood of the car and let everyone see what you’re doing all day. Pretend our software is a pair programming partner. Then stand proudly on what you’ve done. Sign your work. Don’t hide it and hope for the best.
Subversion ( SVN ), the popular source-code control system, has a command to see the changes to a file by user. It shows a file annotated line-by-line with the user responsible for authoring it. This command has two names: blame and praise. Whenever I jokingly suggest using "blame", developers will often respond, "you mean praise?"
Read More
Every development organization I've talked to thinks this is exciting. This is a longstanding problem. Managers want metrics, managers' managers want metrics, but no one wants to slow the project down to gather information. There were solutions like this in the past that made it a little easier but no one makes it quite this easy.
~ Carey Schwaber, senior analyst with Forrester Research
Neil Ford has a great quote about test automation.
We're running too late to stop for gas.
Read More
We all know that developers can't estimate time, don't we? But why not? Developers are very smart. We deal with abstract concepts every day. You'd think we'd be able to learn this skill over time. But somehow we never get better at work estimation. Some people attribute it to a developer's innate optimism, and that's part of it. But there's a more important factor here.
Read More
This is a serious question... take a moment and think about what happened to your last unsuccessful project. The list is usually contains the same 'usual suspects'.
Bad requirements. Moving targets. Crazy estimates. Unrealistic deadlines.
On Monday I spoke at this year's Academy for Software Engineering Educators and Trainers and got to spend some time talking with Watts Humphrey. He asked me this question.
Read More
Noted RedMonk industry analyst Michael Cote did a webcast interview with me about the 6th Sense Analytics product suite and how we integrate with the JIRA feature/issue tracker software. We’re a very nice addition to your Jira install. We easily pull data out of JIRA and then provide additional reporting and trending features.
Read More
What's the best way to use tools like continuous integration or 6th Sensor Analytics? Should we see a problem and hit developers over the head? Scream and run around? Or force developers to follow a rigid set of steps to "guarantee" success? (Herd those cats!)
Much of Agile is about being flexible. It's about getting feedback and adjusting your daily practices to match. This is why so many people have rejected the idea of universal best practices completely.
Read More
For this interview we've got Ken Pugh talking about what he thinks you should be doing over the next year and his favorite career tip. Ken's video is a bit shorter than the Scott Davis post, but he's got some interesting insights on becoming a domain expert.
Read More
Real developers write code — not status reports.
I Need It
There are typically 2 reasons for needing status reports: 1) collaboration and 2) monitoring.
Agile shops recommend status reports for the first reason. Software development is a team sport. Rarely do individuals work in a vacuum, so regular status is important to address dependencies, remove blocks, and ensure folks don’t step on each other’s toes. The manager may collect reports for logistical reasons, but the reports aren’t for managers — they are for the team.
Monitoring is more common in consulting arrangements. Work is being done on someone else’s behalf and that person wants to monitor the activities. Very simply they want to ensure they getting what they are paying for. Every once in a while you read about dysfunctional uses of status reports. This “use case” is commonly the scenario where that’s found. The reason is that people often don’t care until there is a problem. Then the reports are reviewed to help understand where things went wrong.
Read More
This is the first post in a series of video interviews with software development industry notables.
I recently had a chance to sit down with Scott Davis and discuss where he sees our industry going this year. He also has some sound advice for any ambitious developer planning their next career move. And for those of you that don’t know Scott, he is a fellow No Fluff, Just Stuff speaker and author of several books including Groovy Recipes and GIS for Web Developers.
Read More
