|
|
Hrmm.. I take it you're asking since you have a question mark - even though the sentence is not a question. 
Maybe you could do some sort of fancy layout or something with a separating line near the bottom to separate a footer or something and make the line actually a box, but the inner height demension is only about 1/100th of a millimeter and then write your big changes in there with an ultra-high-resolution printer and a font that's only about 1/1000th of a millimeter high (give or take)
Then get them to sign off on it... Though you may still have a little trouble down the road... 
|
|
|
|
|
We have a in-house system that we use for RFC management for a number of applications we build. However we make changes to our RFC system all the time without using RFC at all - go figure.
|
|
|
|
|
Al Ortega wrote: However we make changes to our RFC system all the time without using RFC at all - go figure.
Or in corporate jargon, you don't eat your own dog food 
|
|
|
|
|
I read this as "request for change" as in a formalized bug report/feature request process; completely different than RFC writing. Had the poll creator used the well recognized RFC acronym and/or provided a link to a definition, there had been no question.
I want to change my answer.
---
Shawn Poulson
spoulson@explodingcoder.com
|
|
|
|
|
Shawn Poulson wrote: I read this as "request for change" as in a formalized bug report/feature request process; completely different than RFC writing. Had the poll creator used the well recognized RFC acronym and/or provided a link to a definition, there had been no question.
RFC writing is not a standard. the RFC process changes from company to company, and an the RFC acronym c an stand for many things.
|
|
|
|
|
Further proof a definition would've been helpful. Better luck next time, I guess. 
---
Shawn Poulson
spoulson@explodingcoder.com
|
|
|
|
|
...Than I hoped.
In the company that I work for, and the organization that I develop in, we are in the middle of standardizing on a formal process. We are using the ITIL approach (http://en.wikipedia.org/wiki/ITIL) and for our purposes this is working (maybe because ive developed two apps that are ITIL based, before joining this organization).
But im glade to see that the poll results are so close.
Thanks everyone.
|
|
|
|
|
Send a RFC to MS and if you are a single user then MS just ignores even good requests (fix that hole!).
djj
|
|
|
|
|
This has to be the most evenly distributed I've seen so far. All the choices are sitting around the 25% mark. I wonder if it will stay that way...
|
|
|
|
|
My thoughts exactly.
Cheers,
Vikram.
"whoever I am, I'm not other people" - Corinna John.
|
|
|
|
|
With an RFC, besides creating a quagmire of review boards, processes, and general bogging down an agile development process, a much better approach is an active one--version control to track changes, unit tests and regression testing to validate that nothing broke, and new unit tests to validate the new/changed features.
Given that environment, an RFC is pointless, and everyone can simply focus on getting the job done.
Marc
Thyme In The CountryPeople are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
No.
In a good RFC-Process, the customer want to have some nice features. The project leader discuss the wishes with customer AND the developer team to find a good calculation for effort and cost. The customer agree to the cost and MUST pay after deliver. The cost factor and the "get the money really from customer" is a very important and heavy process.
PS: I vote for "Yes"
BR
Stephan
\\\| \\ - -
( @ @ )
+---------------oOOo-(_)-oOOo-----------------+
| Stephan Pilz stephan.pilz@stephan-pilz.de |
| <a href=http:
| ICQ#: 127823481 |
+-----------------------Oooo------------------+
oooO ( )
( ) ) /
\ ( (_/
\_)
|
|
|
|
|
Stephan Pilz wrote: the customer want to have some nice features. The project leader discuss the wishes with customer AND the developer team to find a good calculation for effort and cost.
Ah, there's a difference between application requirement RFC's and code RFC's. Given the way the survey was posted, I'm assuming the discussion involves making code changes. For example, the customer provides an RFC for a new feature. Yes, this gets evaluated. But it does not generate a slew of code RFC's, IMO.
Marc
Thyme In The CountryPeople are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
|
Most definitely. 5: rose:
Anna ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
Currently working mostly on: Visual Lint 
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
Marc Clifton wrote: With an RFC, besides creating a quagmire of review boards, processes, and general bogging down an agile development process, a much better approach is an active one
I quite agree - But some organisations are far to political to let that happen. An RFC is, for the most part, a political tool rather than a useful tool.
|
|
|
|
|
Marc Clifton wrote: Given that environment, an RFC is pointless, and everyone can simply focus on getting the job done.
Being fast and agile is great and everything, but without a document stating what the coder(s) should do, how does everyone know when the job is done? Seriously.
I welcome RFCs if only to CYA and ensure you're delivering what the business unit is expecting.
Your mileage varies, obviously.
Sean
|
|
|
|
|
Sean Michael Murphy wrote: but without a document stating what the coder(s) should do
Telling a coder what he "should" do from an RFC is the worst possible approach. A coder needs to be told "how" to do it.
Marc
Thyme In The CountryPeople are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
The "Request For Change" process assumes that the business makes requests for change that the technology team implements. I have seen such an approach cause serious problems due to the lack of a *strong* project manager. A good project manager has to give importance to *Quadrant II (important and not urgent) activities* - i.e., they have to look at the product as a whole and make changes that should be done now to prevent firefighting later.
I think that any Request for change process can work effectively only if there is a product team that combines business and technology functions. They should work on making priorities -- whether it be refactoring, changing architecture for supporting future requirements/correcting mistakes made earlier or implementing new features. I believe that the product team should be the one that makes the final call regarding changes in a product -- and should not be *bullied* into doing changes that are targetted at short term rewards -- especially if the product itself is expected to have a long life.
modified 29-Aug-18 21:01pm.
|
|
|
|
|
I said No to RFC but at the same time we don't just dive in and hope nobody notices. Basically we talk about it, think about what it affects (and have our test suite on CI to make sure it covers the bits we didn't think of), do some iteration planning and then go for it.
Bits of paper signed by leads is a terrible idea. It encourages devs to not be involved in their projects.
|
|
|
|
|
You were still correct in voting no, the question was about "Formal" requests, not about discussion groups.
DB_Cooper1950
"Life is like a box of..."
|
|
|
|
|
as CMMI imposes us to, Yes, we all make Chage requests here.
now the question is : "What is CMMI ?" 
|
|
|
|
|
Change Management for Military Ingineers.
Chris Meech
I am Canadian. [heard in a local bar]
Nobody likes jerks. [espeir]
The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]
I wish I could remember what it was like to only have a short term memory.[David Kentley]
|
|
|
|
|
OK, so what is a "Request for Change" process?
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
