Editor's Daily Blog: Who's to blame

If software is a craft, shouldn't pride in your work be a motivating factor? What does it take for you to feel responsible for your work and to do it to your utmost? Who else needs to know which particular part was yours for you to be motivated to produce the best results possible?

In Extreme Programming (XP) there is a notion of no code ownership. The idea is that all production code is written in pairs. The pairs are dynamic so that your partner this afternoon is likely to be different from your partner this morning. If code that you are working on needs to be fixed, then it is your responsibility to fix it.

In his weblog entry @author:Bob the Builder, Meeraj Kunnumpurath writes that in his experience this doesn't work. In his environment they found it necessary to have every developer use the @author tag in the classes they developed. The ten worst and best components along with the authors were displayed on a board. Meeraj said that the motivation to not appear on the Hall of Shame resulted in better code, pride in their work, and responsibility.

He writes:

Code that is not owned encourages poor coding practices that lead to totally un-maintainable code and ultimately utter anarchy. This isn't anything specific to our industry, whatever craft you do, it is extremely important to take pride in your work. It is important to let people know it is your piece of work. It is not about promoting finger pointing or blame culture. It is about having pride in your work. It is also a mark of responsibility. It is about taking ownership and having the motivation to produce better results.

Let him know what you think in the talkback to his blog .Follow-up: as was pointed out in the talk back below, the author isn't allowing talkback on his blog. Feel free to add to the discussion here, instead.

The other featured Weblogs include Will Iverson's entry A Saga of Palm Java Development. Will is wrestling with the decision of whether to use Java or C/C++ for Palm application development. J2ME technology evangelist Bill Day responds to reader feedback in Sun, Apple, and J2ME, Oh My!. At the core of his entry is the discussion over whether Sun or Apple should be responsible for providing the J2ME development environment for Mac OS X.

In the Also Today section, we feature a tip on Producing MIDI Sound using the appropriate Java APIs. It doesn't take much to supplement your application with audio cues using the javax.sound.midi package. The second link is to a spam fighting utility called Mailinator. The idea behind this web application is simple: the best way to eliminate spam is not to give your real address in the first place.

From the Java Today News Page, news editor Steve Mallett, has gathered the following News Headlines .

This blog is delivered weekdays as the Java Today RSS feed. Once this page is no longer featured as the front page of Java Today it will be archived at http://today.java.net/today/archive/index_08052003.html. You can access other past issues by changing the address appropriately.

Bookmark blog post:

del.icio.us

Digg

DZone

Furl

Comments

Comments are listed in date ascending order (oldest first) | Post Comment

Ownership starts before coding
The weblog itself doesn't seem to allow discussion, so I'll post here. Ownership means being involved before writing the code. You want to feel like you had input into why the code was being written, such as being part of the design, reviewing the requirements, etc. If I'm told precisely what to do and where, I'm not much more than a scribe and have little ownership.

Unfortunately, this lack of ownership is the rule rather than the exception in most of today's companies. Personally, I think it has to do with the well known "we need to ship it" mentality which encourages doing as little as possible as quickly as possible to make it work. This mentality tends to bypass the input on requirements, gets limited if any design, and leads to hacked code no one wants to own. Given only one criteria, do it fast, most engineers can't stand the resulting code and lament "I could have done so much better if we'd had time to think things through."

XP supposedly owns code as a group and everyone is supposed to refactor any problem code. XP also says you design as a group and review requirements as a group. If you do all of that together, you've got ownership before the code is written and it probably works.

I'm not convinced the @author tag really helps unless it's a one-off, relatively short term project (which is the archetypical XP project). If it's a long term project, many people will have changed the file significantly over time. The original author's code has long since morphed into something new and it's hardly fair to blame the original author for problems that creep in. I suppose you could have everyone that touches the file add their name to the @author list, but given most changes aren't wholesale across the file they aren't really responsible for most of the code either. So, over time, the file doesn't really belong to anyone and the @author tag has little value.

Posted by: ckessel on August 05, 2003 at 08:37 AM

Flogging Posts and Ducking Responsibility
If they needed the @author tag there to be motivated to produce good code, start phasing them off the project.

This condition is similar to scratching someone else's car and failing to contact the owner. Essentially dishonesty and the lack of personal responsibility.

If they did not know that their code was failing to meet the minimum standards and improved out of pride, that would be understandable.

Of course, I am somewhat sickened that public humilation is being used as a motivator.

Posted by: jol on August 05, 2003 at 10:35 AM

I don't know who's to blame, but...
If you have pride and take ownership in your work, you'll go to great lengths to make sure that projects you're a part of are the best they can be, whether that means learning from or influencing others. You'll share ownership of the project as a whole, and associate with like-minded individuals.

If you possess these traits, it doesn't matter whose name is in the @author tag.

Posted by: d_bleyl on August 05, 2003 at 12:31 PM

COLLECTIVE code ownership
The extreme programming practice you mis-remembered is really called Collective Code Ownership. Every single member of the team is responsible for the quality of the code.

In an XP shop it will be blindingly obvious who is the source of the smelly code. Pair programming will quickly point out who is not meeting the team standard. More importantly, pairing will encourage the laggard to get up to standard in a positive manner without requiring public shaming.

Posted by: tekwerx on August 05, 2003 at 02:02 PM

Just another example
of the wacky things you'll be doing on your next XP project. Although I've never encountered this type of public humiliation technique XP tends to bring out the worst in people. Here are some other weird practices actually sanctioned on the XP wiki:

http://www.c2.com/cgi/wiki?RolledUpNewspaper

http://www.c2.com/cgi/wiki?ZenSlap

http://www.c2.com/cgi/wiki?BrutalSarcasm

Posted by: tcowan on August 05, 2003 at 02:38 PM

I think you missed the point(s)
You appear to have missed several points:

1. the humiliation was not necessarily from an XP shop. the idea of "Collective Code Ownership" was the XP idea Daniel was discussing. The "Bob The Builder" post may have been an XP shop, but I didn't really get that they were.

2. c2.com isn't the "XP Wiki" ... it's just Wiki. It was wiki before there was wiki. While it has been very XP at times, it's also had other flavors over the years.

3. No one can really "sanction" ideas for XP...you take what you want from it, and reject what you don't. There's no Pope of XP who approves and rejects techniques.

It sounds like you've had some pretty negative experiences with XP. That's not surprising, since so many shops are embracing it: some are bound to get it wrong, and some parts of XP are bound to annoy everyone.

I think Daniel makes a very good point here: the quality of the system is the responsibility of all the developers, not just the one who wrote the code. In an ideal team, members would be motivated by a sense of "caring" for the system, almost as if it were a living thing, rather than by shame and peer pressure.

Finally...read ZenSlap again. It's a Zen Story, not an XP technique.

Posted by: mdi on August 05, 2003 at 08:21 PM

you take what you want from it, and reject what you don't
If there's no "pope" or standard to define XP how can you make the judgment that some shops are "bound to get it wrong"? Maybe they got it right depending on what they decided to accept or reject. Perhaps we'll never know.

If the point is that we are to care for our software as if it were "a living thing" then I'm glad I missed it. I'm completely lost on that one.

Taylor

Posted by: tcowan on August 05, 2003 at 10:10 PM

Collective Ownership
Ownreship doesn't necessarily mean individual ownership, it is collective ownership as well. I was using @author tag just as an example. As I said it is not about public humiliation or promoting blame culture. It is about encouraging team members to assume responsibility for their work.
BTW I didn't delebarately disallow talkback on my post :-) It was my first post and I missed it.

Posted by: meeraj on August 06, 2003 at 01:30 AM

Culture shift
I didn't think the lack of talkback was on purpose :).

I think the main issue is that culture change is slow and if the @author tag works to help change your culture, great. I just don't think it's a good long term solution for code ownership since as the project matures the code will have been touched by many people.

Posted by: ckessel on August 06, 2003 at 10:55 AM

XP practices and collective ownership
I'm working on a large project at the moment, and we are using XP practices on sub-components - quite effectively.

On a larger project not everyone can own the code, but the @author tag can be used effectively to identify the subgroup that collectively owns the code.

Disclaimer: The project I am working on does happen to be the same project as Meeraj...

Posted by: bob_boothby on August 07, 2003 at 04:08 AM

Ownership and humiliation are not the same thing
It has been my experience that virtually every team member wants to do a good job. Further, given a clear idea of what "good" entails, all of them will, in fact, do just that. When I find someone falling down on the job, I often discover that they have a different understanding of the goals and standards for the code. Further, they are not always wrong about those goals; reaching a team concensus usually results in aligned goals.

I am very fond of many aspects of XP. Unit tests, short iterations, and stakeholder involvement are all very, very good ideas, and combining them works well. Further, many of the scripts XP books suggest, such as "how to explain that the user can chose a feature set or a delivery date, but not both" are very well written.

I am not so fond of the "software bullying" I see proposed by many XP advocates. This should not be a part of XP, but I have seen several teams where this was the actual management style.

Put another way, if you are about to call someone's code rotten, smelly, or worthless, do yourself a favor and just fire them. You will never be forgiven an insult, but a termination might result in someone who is willing to work with you again, come the day. If you do not think that your "fighting words" are worth termination, then reconsider your phrasing.

I do not mean that you should avoid fixing bad code, or that you should accept inferior work. Especially in a mentoring situation, it is important to identify what is wrong with code and with someone's understanding of the craft. What I take issue with is the implicit "we are all on the same page" message which assumes that people just are not working hard enough, and thus they belong on the board of shame if their code is not what you expect.

Simply put, acceptance tests are how you measure quality for your code. Use the same standard for your team - if a member is not meeting the spec, come up with a way of testing that automates their skill acquisition. A good way is an actual discussion of the purpose of a "smelly" module. Ask whether they thought it would be used in the ways it is being used, and then figure out how to bring it up to functioning speed.

For example, build failures waste the time of the entire team. I see nothing wrong with posting a build failure message to the entire team, as long as there is a way for a developer to integrate and test before putting their code on that server. They thus can avoid embarassment by doing their job properly with the tools they have. Only someone taking a shortcut or not doing proper work will get nailed by such a message, and in my experience, few people make that mistake twice.

The difference, to me, lies in how often someone gets hit by these brickbats. Breaking the build is a bad, bad thing, and I have seen it happen perhaps a dozen times in the last year. This is far different from a weekly "ten worst modules" list, or publication of the "least productive" workers as I have seen suggested here and there.

We rarely use author tags where I am. Instead, we tend to follow the cvs logs. That said, we all have a pretty good idea of who to talk to about problems, and thus we are all careful to get a feeling for what people feel an ownership stake in.

In short - consider that someone may well think the code you find "smelly" is actually well written, just not for the purpose it is being used for. If you do not come to a concensus on the standard the code should be written to, then an offhand comment may well make someone very, very angry, and justifiably so.

Posted by: scottellsworth on August 27, 2003 at 03:28 PM

网络营销软件
网络营销软件
网络营销软件
群发软件
群发软件
---
群发软件
网络营销软件
论坛群发软件
网站排名软件
群发软件
推广小助手破解版
论坛群发软件
网站排名软件
群发软件
推荐给你很好的群发软件和信息群发软件和供求群发软件
推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件

群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
网站排名软件
博客群发软件
网站排名软件
网站推广软件
群发软件信息群发软件
免费论坛群发软件
论坛群发软件
网站排名软件
免费博客群发软件
网站推广软件

群发软件
博客群发软件
网站排名软件
网站推广软件
群发软件信息群发软件
免费论坛群发软件
论坛群发软件
网站排名软件
免费博客群发软件
博客群发软件
信息群发软件
论坛群发软件
信息群发软件
博客群发软件
qq群发软件
邮件群发软件
博客群建软件
企业名录搜索软件
信息群发软件
邮件群发软件
论坛群发软件
博客群发软件
网站推广软件
网络营销软件
全能营销破解版
网络营销软件
论坛群发软件
论坛群发软件
论坛群发软件
网络营销软件
信息群发软件
信息群发软件
信息群发软件
群发软件

Posted by: mimi9989 on December 06, 2007 at 02:24 PM

wow power leveling
wow powerleveling
wow power leveling
wow gold
wow items
feelingame.com
wow tips
Most Valuable WOW Power Leveling Service
wow power leveling faq
cheap wow power leveling
wow power leveling
wow powerleveling
wow power lvl

Posted by: wowleveling on December 13, 2007 at 09:11 AM

Powered by
Movable Type 3.01D

java.net RSS Feeds