Originally posted by Reid M. Pinchback:
Even Cockburn, who you like to quote, admits that the amount of process oversite required for project work depends on the scale and risks of the project.
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:
So, if I take the step back and see that some of my work is process work - what should I do about it???
Maybe. OTOH, maybe they just use a form of requirements management you aren't used to. Perhaps they even think of you as being in fear of their form of requirements management?
I assume as rude as it sounds to me - you probably agree that there are many projects that are much more complex than a simple subsription website but where a single failure won't cause the loss of life or ruin a whole corporation.
Rudeness objection - I don't find it very constructive to assume that this "obfuscation" is done mischievously.
Are you sure that your definition of "process" is the only valid one?
Reid - SCJP2 (April 2002)
Originally posted by Frank Carver:
I try and communicate this by saying something like "there are no 'soft' requirements. If you want it, decide much you want it, and tell us how we'll know when you've got it". Ron Jeffries probably has a stronger and more pithy way of saying that if there is no acceptance test for something it just doesn't exist.
Can you give me an example of such a soft requirement which is (a) really needed by the organization, (b) is always more valuable than (for example) delivering a usable increment of functionality to a customer, and (c) for which it is impossible to formulate an acceptance test? If you can. I'l concede the point.
Reid - SCJP2 (April 2002)
Originally posted by Frank Carver:
I'll buy this, for most of the kinds of cases you describe, but only where all cost-effective possibilities of automation have been exhausted.
...
So I'd hope to see (for example) automated port-scan and buffer-overrun tests as part of a security test suite, and tests added for specific known exploits just as tests are added for faults discovered "in the field".
I wouldn't be happy with a blanket statment that such problems are "too hard to test, so we won't do any testing".
I asked my usual "how do you know if/when it is done" question, and got the answer that we probably won't know until either it is tested in court with some sort of unfair dismissal case or it pays off in very wishy-washy recruiting and corporate performance terms.
Reid - SCJP2 (April 2002)
Originally posted by Reid M. Pinchback:
Security issues (particularly for 3rd-party systems brought in-house - hence no source code to examine). Since you can't prove a negative, you can't prove that a system can't be broken into, hence you can't automate an acceptance test to prove it can't be broken into. You can clearly describe the kinds of investigation that you want performed on the resulting system before certifying it as acceptable. Automating the investigation could be cost-prohibitive.
Java threading issues. [...] You can choose algorithms known to eliminate deadlock, but you can't really test to see if the algorithm was implemented correctly.
Usability and brand identity. Hard requirements describe functionality, but usability and branding issues are subjective and you have to try and assess what the 'typical' reaction would be of your customer base.
I'm assuming that by 'soft' you mean something that is infeasible or impossible to automate, then I can do that easily.
In regulated environments (e.g. software done in support of drug development), you have the perfect example. Drug development regulations (e.g. CNIL, FDA) are very stiff. You side-step your documented development process at extreme peril, and the regs determine some of the characteristics of that process and some requirements for the deliverables (e.g. auditability and security).
On the purely technical side, data architecture is another example. I've seen uncoordinated data designs across multiple projects result in rapid explosion of almost-duplicate data in an organization that can't be unified.
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:
So, if I take the step back and see that some of my work is process work - what should I do about it???
Standardize it and determine what is required to be able to retain the process. Document the required inputs, the steps involved, skills necessary, the outputs that will be generated.
Support management efforts to collect data on the process so that resources can be allocated effectively (and help managers do one of their jobs - provide some proof of the productivity of their staff during the typical annual budget wars). Do what you can to make other forms of work be done in a way that allow the process to exist.
If I had invented it all by myself, you would have a point. However I didn't, this is old hat in the process improvement/process management world (a big part of my job, apparently not something that drives yours, so terminology expectations will likely differ... and that was exactly the point I was trying to make).
I assume as rude as it sounds to me - you probably agree [...]
Hmmm... first time I've heard somebody claim I was rude because I agreed with them.
Particularly when the point I was making was straight out of the project complexity/risk continuum described by Cockburn. Guess I just assumed that by providing the two extreme points, a smart developer (e.g. you) would connect a line between them and draw the obvious conclusions. Congrats; looks like you did.
Maybe the word 'debate' translates into something more derogatory in your native tongue than it is in English.
At the risk of being "rude", how the heck do you ever expect people to agree on anything if they base their discussions on different semantic concepts? [...] The first step is to clarify the underlying semantics so that all the issues are on the table. Doing so is not rude. Not doing so would render any debate pointless and any apparent conclusions highly suspect.
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 Frank Carver:
Where I work at the moment, for example, it makes no perceptible difference to the company turnover, profit or share value whether each individual does his or her job well or badly. On the other hand it makes a lot of difference to personal satisfaction, annual pay rises and bonuses if people play the game of internal politics well. "Empire Building" - getting to be in charge of as many people and as much budget as possible; "Blame Avoidance" - it doesn't matter whether something succeeds or fails, as long as you don't get blamed for failure; "Brown Nosing" - associating with people with the power to improve your own position, and so on.
[a good configuration management example]
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
Matthew Phillips
Originally posted by Matthew Phillips:
I have been quietly following the thread. It has a lot of really good information for a newbie like me.
I read an article today relating the problems with XP. Since that is the topic, I thought I would post it and get some thoughts from the heavyweights here.
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
Reid - SCJP2 (April 2002)
Originally posted by Ilja Preuss:
So, what do you think so far?
Matthew Phillips
Originally posted by Ilja Preuss:
IIRC, you mentioned configuration management as one part of process work. Perhaps you elaborate on this example what data you would suggest to collect and what other forms of work would be adjusted to allow the process to exist? Thanks again!
Originally posted by Frank Carver:
...
Aargh. Configuration Management nightmare.
Originally posted by Ilja Preuss:
This way half an hour after you commited your changes, you know wether you broke anything in other projects.
Reid - SCJP2 (April 2002)
Reid - SCJP2 (April 2002)
Originally posted by Frank Carver:
In this environment a shared repository accessible by a single Cruise Control is a pipe dream.
Reid - SCJP2 (April 2002)
Originally posted by Ilja Preuss:
I am not sure about this - once you identified the duplicate data, wouldn't it be possible to test that the projects are using the same data storage?
You can choose algorithms known to eliminate deadlock, but you can't really test to see if the algorithm was implemented correctly.
...
Why? Aren't these algorithms deterministic?
Reid - SCJP2 (April 2002)
Originally posted by Matthew Phillips:
I read an article today relating the problems with XP.
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:
Ultimately it is a matter of coordinating the design of the data elements for the two programs so that you are in a position to assess the similarities and differences. If nobody is responsible for managing the cumulative impact of the data designs, you have a classic example of a tragedy-of-the-commons problem, where nobody owns the job of managing the resource (data and knowledge in this case) that everybody depends upon and yet gradually damages through their use of it.
That still leaves the issue of testing. Testing will tell you if the test detected a bug; it won't prove the absence of one.
Since threaded applications are essentially non-deterministic, you usually have no way of constructing a test with sufficient coverage.
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 Frank Carver:
Where I work, having any version control at all on a project is nice, but useful version control for developers is very unusual.
There is no way that separate projects would ever submit to using the same version control software. In this environment a shared repository accessible by a single Cruise Control is a pipe dream.
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:
Proposed system connections may not be as feasible as assumed in initial verbal discussions. The key data concepts form a protocol between connected systems, and if the systems don't have data notions that can be rendered compatible, they can't be integrated (or at least, it will take a lot longer than the project schedule may have made allowances for).
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:
It doesn't work so well with multiple branches [...]
[...]it doesn't work if the acceptance criteria includes measuring in-situ performance levels (a common requirement for trading systems).
I haven't seen studies about it, but from my experience I think CM-based failures might cost more than requirements failures.
As an example of things that need to change to support a CM process:
1) Requiring developers to check in source code
2) Requiring developers to use the same versions of libraries that are used in the build process (if changes are needed, update the libraries used by the build)
3) Designing systems into cleanly factored components and eliminating spurious dependencies. A lot of lifecycle problems have their roots right here, including CM shared source management difficulties.
4) Standardizing on tools where possible. That doesn't necessarily mean that everybody should use the same IDE, although that can be an attractive solution (you can create pretty streamlined CM processes around a single shared development environment). You want to make sure that you've checked in everything that matters for creating your product, and that more than one person can use that material once it has been checked in.
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:
[...] that isn't the strongest reason I can think of for having written requirements. I know of several:
1) up-front resource estimation (it is easy to turn good requirements into a pretty accurate estimate of the resources required to create the deliverables on a given schedule).
2) parallelism (QA and documentation prep work can begin at about the same time the work starts on the code-based deliverables).
3) validation (in some industries you have to be able to prove that an application was designed and implemented to do exactly what the written requirements contained, no more and no less).
4) buy-vs-build (if you get requirements in dribs and drabs, you may piecewise build something that you could have bought or re-used for a lot less).
5) scale (related to parallelism; teams with many dozens or hundreds of people working on a very large project need non-verbal mechanisms to help keep the work in sync and help the developers identify the portions of the information related to their responsibilities).
6) mounting lag (you can track the increase in new issues and elimination of old issues relative to the original project requirements and schedule to see if you'll hit your target date - done properly you'll know if you can hit your date after 10-20% of the work is done)
Every interesting methodology has its strengths (or it wouldn't have many supporters). It also has its weaknesses, which is why I tend to be skeptical about any methodology that is espoused too much.
I didn't get the impression that the author really bothered to think about the strengths and weaknesses sufficiently to help the reader understand when they should, or shouldn't use XP, or how they could improve on the original concept. It seemed mostly like an attempt to justify an I-don't-like-it position.
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 Matthew Phillips:
I read an article today relating the problems with XP...
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. |