TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPass
Home  >  Detail: Charge of the Light Brigade Considered Harmful



A StickyMinds.com Original
Article Picture
Charge of the Light Brigade Considered Harmful

By Matt Heusser

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Communication problems can be devastating to a project -- Just ask the Light Brigade. In this week's column, Matt Heusser offers some tips that may help you keep your team a cohesive, functioning unit.


Rally Software Development
    “Theirs not to reason why, 
    Theirs not to make reply, 
    Theirs but to do and die, 
     
    Into the valley of death, 
    Rode the six hundred.”
 
Lord Alfred Tennyson’s epic poem is a story of a tragic defeat. Commanded by officers without a clear view of the battlefield and plagued by communication problems, the enlisted men of the light brigade were told to march into certain death, and they did. Instead of learning from this mistake, the lines above are often misquoted and glorified “Ours but to do or die.” 
 
Let’s compare that military chain-of-command structure to a typical, pyramid-shaped software organization. The leadership, several levels abstracted from the work, may not have a clear picture of the situation. In healthy organizations, the line workers may present feedback, which can be used to make midstream course corrections to steer the organization back to safety. 
 
In less-healthy organizations, feedback may be viewed as criticism or personal attack. When this happens, the organization cuts off its own ability to react and respond to change. (And change, after all, is just a fact of life in the software field.) All too often, the only employees who know anything is wrong are too scared to talk for fear of being labeled “not a team player.” As a result, the entire project team, or a large part of it, may willingly and knowingly walk into the valley of death. 
 
Yet feedback, properly aimed, certainly has saved many organizations. In fact, Kent Beck and Ward Cunningham list feedback as one of the four core values of Extreme Programming. Feedback is unquestionably good; the question is how to position the feedback for the right kind of impact. In my experience, the best way to do this is to get ego out of the way and talk about solutions. 
 
We all know that feedback can bruise egos. For effectiveness, it must be positioned so the recipient does not feel insulted or drawn into a spitting contest. A sure-fire way to start a war is to question a decision that has already been made while it is being announced publicly. As hard as it is to do, criticism must be given in private. 
 
Another way to foul up the works is to point out problems without offering solutions. This is a simple, natural human tendency. A discussion of an unrealistic schedule that includes a simple working system, which delivers value quickly will probably go over much better than a gripe session about how management is unfair. 
 
It’s human nature to enjoy talking more than listening. A thirty-second accusation will probably prompt a five-minute defense from the other person. Listen for the reasoning behind the defensive position. And instead of an accusation, try asking simple, open-ended questions. “What about burning the program to disk?” “What are the issues I'm forgetting?” “What does success mean?” “What trade-offs can we make?” “So, if we find bugs in test, what are our options for fixing those bugs?” 
 
Beware. Even if your feedback is well received, and you find or fix what would otherwise have become a major fly in the ointment, you run the risk of being perceived as the “Savior” who will “put the project back on track.” There is another name for a Savior whose project fails: scapegoat. Amazingly enough, personal ego contributes to this problem as well. The person that pointed out the problems in the project believes that he could run the project “better” or more effectively, and then ties his ego into the project even more tightly than the original stakeholders. 
 
Avoiding the ego trap pays off in multiple ways. The phrase “It’s amazing what you can accomplish if you don't care who gets the credit” also applies to software organizations. Point out problems with the project. Suggest alternatives. Let the people running the project adopt them as their own. You might not get the credit, but the project will be closer to back on track. After all, a career marked by project success will tend to speak for itself. 
 
In the end, if feedback is viewed as career-self-destruction, and nothing changes when feedback is offered, you may have to hit the silk. Do you honestly want to work in that organization, anyway? 
 
If you are a leader, the implication is clear: Don't shoot the messenger. Instead, seek out the dissenting opinion so you can achieve success. As Victor Stone put it in his article “The Rubber Stamp”:
    “Don't you know that a VP can get any 10 monkeys in this company together to rubber stamp just about any crazy idea? But if you want real consensus you have to dig for the opposing view because if you don't seek it early, it will find you later.”
 
Perhaps that’s a better quote to keep in mind when it comes to software projects.  
 
Acknowledgements: Michael Kotman and Dennis Elmhirst made significant contributions to this article. 
 
Further Reading:  
1) eserver.org 
2) www.usafa.af.mil 
3) msdn.microsoft.com


About the Author
Matt Heusser is a programmer/analyst at Priority Health, where he is also chair of the QA Committee for Software Engineering, as well as former Cadet Colonel in the Civil Air Patrol, the United States Air Force Auxiliary. You can reach Matt by email at: mheusser@charter.net

Back to Top
 
 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Mike Klein 5/19/2004

As a tester I tend to bristle at absolute statements like, "Feedback is unquestionably good". As any sound engineer would express, feedback is not good. In software the same sort of out of control positive feedback loop can occur causing feedback to not improve a project but actually kill it. "Analysis Paralysis" is one way that just concentrating on feedback can stop progress. In no way am I attempting to invalidate your major points as I in general agree, it's just that feedback like almost anything else can be overdone. And a quick word on "egoless" feedback. When I was in college the concept of "egoless" programming was fashionable. I...Read On

 
 
Comment:    
by Tanya Martin-McClellan 5/18/2004

Tek Wallah has a good point. It's foolish to assume that everyone has the company's best interest in mind, when evidence suggests that sometimes, some of them have other primary interests.

Author's Response:
5/18/2004    
Again, Tanya, if the leaders in your organization are acting in a way that is fundamentally wrong, youve got that decision to live with it or leave it. If thats the problem, learning from the light brigade isnt going to be enough. The current issue of Better Software Magazine actually has a featured article that deals with "The Liars Contest", and Jerry Weinberg might be able to help more than I ... CLICK HERE.

 
 
Comment:    
by John Daughety 5/17/2004

I have "hit the silk" before, and the main reason was because every software project seemed like a famed "death march". I could look in the eyes of the programmers and know they had no hope that the project would be successful. I have never regretted this move, either, since it is very hard for a project to succeed when the people implementing the software do not believe in it. I liked the point that the poem said "do and die", not "do or die" - a very big distinction when you are in the charge! One of the most difficult things to do as a tester is to remove ego, since in many software development organizations we are considered of a...Read On

Author's Response:
5/18/2004    
Thanks John. You and Tek make the interesting point that some things are just up to management to decide. The decision to 'hit the silk' is a painful one, it's not made easily, and there's always the risk that you will move into an organization that's worse ... :-)

 
 
Comment:    
by Jon Hagar 5/17/2004

Egoless feedback is always an ideal, e.g. focus on the product or problem, not the people. But many people tend to have so much ownership of products or problems, that any feedback is still seen as an attack. The flip side of this is, we can all do a better job of seeking feedback as well as just "giving it". Being open to feedback can result in a organization culture that seeks feedback rather than being defensive.

 
 
Comment:    
by Tek Wallah 5/17/2004

This is so right -- from the company's point of view. The problem is that the kind of people who rise to power in a corporation don't do it for the company. They do it for themselves.

 
Back to Top


Marketplace

Census: Web-based Bug Tracking and Defect Tracking
Track software bugs, defects, enhancements, support calls, and more. Issue tracking software that is scaleable, fully customizable and integrated with VSS. Includes e-mail notifications, role-based workflow, change history, and Crystal reporting.

New Webcast: How to Profit with Remote Support.
Discover how REMOTE SUPPORT can fuel your IT business in ways you've never thought of before.

Need Agile Test Cases?
Create statistically complete test cases simply and quickly.

Check Out IT Certification Preparation Materials
Sign Up With SkillSoft & Get Access to Training Materials for Over 50 Professional Certifications.

Bug Tracking On-Demand
Looking for the reliable, convenient, secure and completely web-based issue tracking system? BUGtrack allows unlimited number of users, projects and bugs as well as unlimited customer support for a low flat rate.

Get your product or service listed here.
Subscribe to Better Software Magazine
Subscribe to Better Software Magazine

First Name:

Last Name:

Email Address:


Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2008 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


HP: Pillars of Application Quality

Software Quality Engineering

STARWEST 2008

 
Agile Development Conference 2008