Better Software - May 2008 - (Page 34)

It was with this thought in mind that we mounted our trusty steeds (Firefox) and visited our magical search engine, Merlin (aka Google), on a quest to discover the exact code of chivalry by which ancient knights lived. What we found was that there was no single ancient code—ancient knights and authors described knightly virtues differently. However, the various ancient codes were combined and updated into a modern code of chivalry in 1997 by Brian Price, an expert in medieval history. In Price’s modern rendering of the ancient code we believe we’ve found the Holy Grail of desirable attributes for today’s chivalrous team members. We start each of the following sections with one of the ten virtues described in Price’s modern code of chivalry. the team works collaboratively to solve problems, individual fame evaporates and is instead shared among team members. For some this is a difficult transition. Justice Seek always the path of “right,” unencumbered by bias or personal interest. Recognize that the sword of justice can be a terrible thing, so it must be tempered by humanity and mercy. If the “right” you see agrees with others, and you seek it out without bending to the temptation for expediency, then you will earn renown beyond measure. only be self-organizing when each team member freely gives information and assistance to other team members without a need for personal gain. True belief and loyalty in the development ideals you choose to live by must never be waived. Loyalty to our customers and stakeholders is also important. As developers we give the business control over priorities. As team members we must stay loyal to these objectives and not think we know better or make our own judgment on what the business “really needs.” Courage Prowess To seek excellence in all endeavors expected of a knight, martial and otherwise, seeking strength to be used in the service of justice, rather than in personal aggrandizement. We’d certainly like to work with team members who seek excellence in all endeavors. Before Mike began his career as a consultant, his main criterion in deciding whether to join a company or team was whether there were individuals on that team from whom he could learn. Not only does being around others who pursue excellence in their endeavors provide learning opportunities but it also pushes each of us to be our best. If we know that our team’s DBA is writing sloppy code in the database because he doesn’t think this product will be around for the long term, then we, too, are more likely to write sloppy code. Of course, if excellence is sought solely for the sake of personal gain, then it does not benefit the team. The ideal team member is one who seeks excellence because it helps the team as a whole. Prowess extends to resolving problems that are “not mine.” This should be done not for fame but for the betterment of the product. Martin has observed that often when a team starts to work together more collaboratively, some of the stronger subject matter experts struggle to become part of the team. Strong subject matter experts are used to acquiring fame for resolving difficult problems. As 34 BETTER SOFTWARE MAY 2008 Ruby on Rails is currently a hot technology, so Mike wasn’t surprised to see it in use at one of his client sites. What did surprise him was that this particular client was using Ruby—it had used and was still using Java for all its other development work. A number of Java systems built over the past five years, new projects beginning in Java, and one new project in Ruby on Rails seemed an odd combination. After a bit of questioning it became apparent why the new project had been started in Ruby on Rails, and the reason is one that underlies too many technology decisions—the project was being done in Rails because the two senior developers on that project wanted to add Rails experience to their résumés. Any doubts about this evaporated six months after the project started when one of the senior programmers left for a shiny new Rails job. Someone who always seeks the right path for a project, unencumbered by personal interests or bias, is definitely someone we would want as a team member. Being a knight often means choosing the more difficult path, the personally expensive one. Be prepared to make personal sacrifices in service of the precepts and people you value. At the same time, a knight should seek wisdom to see that stupidity and courage are cousins. Courage also means taking the side of truth in all matters, rather than seeking the expedient lie. Seek the truth whenever possible, but remember to temper justice with mercy, or the pure truth can bring grief. Loyalty Be known for unwavering commitment to the people and ideals you choose to live by. There are many places where compromise is expected; loyalty is not amongst them. A team member displays loyalty in a number of ways. You need to believe in the principles and goals your team has agreed to follow. If your team has chosen to do a daily build and to never go home while the build is broken, you must be loyal to this precept. You must be loyal to your fellow team members even in times of stress or conflict. A team can www.StickyMinds.com It can sometimes be difficult for a team member to be the bearer of bad news. No one wants to admit at a daily stand up that he needs assistance. Martin recalls the first time he needed to seek help from his team: “I had just been exposed to objectoriented programming after a decade of procedural programming on mainframes. I was struggling and needed help. However, a feeling of guilt and failure came over me in the daily stand up, discouraging me from expressing my problem to the team. I tried to avoid asking with delay tactics and some dodgy procedural programming hacks. Eventually, when I did ask, I was pleasantly surprised with the reactions of my team members. People congratulated me for saving days on the project by expressing my problem quickly so that a resolution could be found and acted on by the team instead of burning money in a solo effort that would most likely have ended in failure.” It takes courage to tell your teammates you need help. Such courage should be encouraged, because by speaking openly you are seeking the best results for the team. Courage is also required when speaking with clients or management. http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - May 2008

Better Software - May 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: It's A Bug! The Chivalrous Team Member Let's Talk Agile Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.