ASCII silly question, Get a silly ANSI.
Reid - SCJP2 (April 2002)
Reid - SCJP2 (April 2002)
Originally posted by Reid M. Pinchback:
If you want the opposite viewpoint, you could argue that the proprietary model allows specialists to do their thing. For example, creating high-performance persistence layers for clusterable J2EE apps isn't something you learn to do overnight. Having somebody who knows how to do it work on the code and descriptor files can make sense.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Reid M. Pinchback:
In the proprietary model you have to persuade the author to make the changes (which can put them on the defensive; after all, you are complaining about their work) *and* the author has to have the time to make the changes. Even if you aren't worried about the former, the latter means individual people become resource bottlenecks.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Yes, it can make sense. But to do that, she doesn't need to *individually own* that code, does she?
Reid - SCJP2 (April 2002)
Originally posted by Stuart Ash:
Conventional Tenet: All code has known authors. By and large, each unit of code (typically class) has a main author, who has a sense of ownership.
Agile Proposition: Any code anywhere can be changed by anyone at any time.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Originally posted by Paul Clapham:
In theory anybody can change any code at any time, but in practice we have specialists who work with a certain subset of programs. So if somebody wants to change the pricing module that uses 33 database tables and is called by any program that wants to know how much we are going to charge Customer X for Product Y today, they are almost certainly going to talk to the person who regularly works with that code. But if they have a change to make to it and they know what they are doing (KEY POINT), then they can make the change themselves. What this means is that both the Conventional and Agile rules apply, and there is a creative tension between them. We don't want people changing our pricing algorithm willy-nilly, but we also don't want to prevent people from making necessary changes.
The concern, I expect, is that I could put something into the pricing algorithm that gave my brother's store a good deal and that nobody else would notice.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Jeanne Boyarsky:
Technically the agile code has known authors. You just have to go into version control to see who they are. I bring this up because we've been talking about "how do you know who touched a piece of code" lately.
We've been doing more of a mix lately with respect to this. Anyone can touch the code, but there is a primary author who knows the most about it. This is a decent mix as it allows specialization and ease of support when someone goes away for a month (or presumably if someone leaves.)
ASCII silly question, Get a silly ANSI.
We are undergoing a Sarbanes-Oxley audit at the moment, and the auditors are not pleased with the "agile" part of our methodology. They would prefer that our software be partitioned into areas with people responsible for the changes made in those areas. I believe the reasoning of the people who make up these audit checklists is that they want any change to the code approved by some identifiable and responsible person before it becomes live code. The concern, I expect, is that I could put something into the pricing algorithm that gave my brother's store a good deal and that nobody else would notice. (In our system one would do that by changing database entries rather than code, but it's hard to explain things to auditors.) Anyway, we will probably deal with this requirement in some creative way that allows us to go on getting our business done, but the message is that "agile" is going to be hard to do in publicly-held North American companies.
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
On the one hand you're right. On the other hand I can't really hate them too much, because I used to be one of them. I can still recall being handed the checklist for the "DP Security" reviews that the consulting company did, and being sent off to a client (about which I knew pretty much nothing) to administer the checklist. I'm pretty sure they lied like hell to me, too, but that didn't really matter too much because the checklists got done, approved, and filed.Originally posted by Scott Ambler:
The real problem is that your assessors are imbeciles. Instead of looking over their pathetic little checklists, why can't they simply look at the check-in history in your version control tool to see who changed the code? Or aren't they skilled enough to do such a basic task?
- Scott
Originally posted by Warren Dew:
I've seen agile teams with two different approaches to "author neutrality".
One is that no one owns the code. When someone needs a change to a library call, he changes the call to make his own client code work, often breaking other code in the process. Since no one owns the library code, no one has the job of fixing this breakage. After a while, the code base devolves into a random mess of bugs. This form of joint code ownership is far inferior to individual code ownership.
The other is that everyone owns all the code. When someone needs a change to a library call, he changes the call, then makes sure not only the code he's working on, but all the other code in the project also works - since he owns that other code too. He can get help from other people if he needs it because they all own all the code as well. This form of joint code ownership can work really well.
ASCII silly question, Get a silly ANSI.
Originally posted by Stuart Ash:
LOL, yes, it's the possibility first scenario that makes you cynical about taking up author-neutrality.
ideally in concert with other stuff such as daily integrated build and unit tests.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Don't get me started about those stupid light bulbs. |