View previous topic :: View next topic
|
Author |
Message |
rakesh1155
New User
Joined: 21 Jan 2009 Posts: 84 Location: India
|
|
|
|
Hi,
First of all, I didn't know where to put this up, so I am posting this here.
We have a requirement1 and requirement2, both needing modifications to the same set of COBOL programs.
Requirement1 is planned to move to production in Release1.
It is not planned when to move Requirement2 changes.
Now does it make sense to have two different developers working on requirement1 and requirement2 simultaneously. And then later, retrofitting the changes of requirement2 to the requirement1 finalized code which would lead to re-testing everything again? |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
I hope your Team-Lead logs-in here - s/he is best suited to answer this question! |
|
Back to top |
|
|
rakesh1155
New User
Joined: 21 Jan 2009 Posts: 84 Location: India
|
|
|
|
Unfortunately he doesn't.
If he did, this forum would have made him smart enough that I would not have needed to put this question up ! |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
What does your site have in the way of change management tools? That will determine how easy (or otherwise) the code merge will be.
You'll need one additional set of testing, true; however, it's going to depend on what your timelines are like (will req#1 and req#2 take the same amount of time to code and test, so that only the merge testing is required, or will there be significant slack doing one or the other?) |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
Actually, in ideal situations, what you say is correct, however - possibly release-2 might be a distant plan as you said, "It is not planned when to move Requirement2 changes".
What Business has to say:
Let's say, on a given Credit Card some bank wants to introduce two different new rewards-systems. To do that, they want to see the response of First-reward-system in the market first - obviously, they plan to release this change little early to get the response from market. If it succeeds, they go for other decided plan otherwise they might modify the second plan and just drop the idea to implement it.
What an Application Developer has to say: Similar thing, what you said.
Keeping above thing in mind, it might make sense to implement both the changes simultaneously from technical per se however, from Business per se, it is not.
If this should be done by single programmer or more, it depends - on your management.
If I were to do it - I'll ask to keep the same programmer if his mileage is good enough. |
|
Back to top |
|
|
rakesh1155
New User
Joined: 21 Jan 2009 Posts: 84 Location: India
|
|
|
|
Hello Akatsukami,
We have Endevor at our site.
The additional set of testing which will be pretty much a duplicate of req#2 testing is my concern. Also, the point that the req#2 testing done prior to code-merge would ultimately be of no value.
Hello Anuj,
Yes, single programmer or more - depends on the management... not questioning it.
I think I should have stressed a little more on "simultaneously".
My concern here more is the additional set of testing required after merge and initial req#2 testing done going waste.
I would better have the code started after the req#1 is done and dusted that will ultimately save some billable hours for the customer. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
rakesh1155 wrote: |
I think I should have stressed a little more on "simultaneously". |
May be you can identify with this:
Quote: |
What Business has to say:
Let's say, on a given Credit Card some bank wants to introduce two different new rewards-systems. To do that, they want to see the response of First-reward-system in the market first - obviously, they plan to release this change little early to get the response from market. If it succeeds, they go for other decided plan otherwise they might modify the second plan and just drop the idea to implement it. |
If this does not help, suggest (as one of the alternatives) talk to someone at your shop with your point of view. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
rakesh1155 wrote: |
Hello Akatsukami,
We have Endevor at our site.
[...]
My concern here more is the additional set of testing required after merge and initial req#2 testing done going waste.
I would better have the code started after the req#1 is done and dusted that will ultimately save some billable hours for the customer. |
That could well be true. OTOH, my shop invariably has several teams of developers working on the same source modules simultaneously...since otherwise we could not implement a fraction of the changes demanded of us (let alone "nice to haves", like new business functionality ). Again, the timelines control; having req#2 being implemented in the sweet by-and-by -- maybe -- is OK, until management says, "You've gone live with req#1? Good; now bring up req#2 this afternoon. No, I don't mean 'tomorrow'; if I'd meant 'tomorrow' I'd have asked for it tomorrow". |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
ROFL -- . I'm thinking why do you quote rakesh1155 ! |
|
Back to top |
|
|
rakesh1155
New User
Joined: 21 Jan 2009 Posts: 84 Location: India
|
|
|
|
Hello Anuj,
Yes, your example does work well for an answer to my query.
So it all depends on scenario to scenario. And for this currenct scenario, from the time-line info I ve got about the req#2, the re-work can be avoided (of course if the intention is not to keep the developer busy).
And yeah, about rakesh1155, when I first started using email... created an email account with this ID and have used the same along everywhere. But 1155 doesn't have any significance... I wasn't born on 1st Jan 1955 |
|
Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006 Posts: 792 Location: Pennsylvania
|
|
|
|
Ok so now you have it.
You checked on the forum and everyone there says in this case with this timeline, give both changes to the same developer.
Tell your manager, and it will be done. |
|
Back to top |
|
|
rakesh1155
New User
Joined: 21 Jan 2009 Posts: 84 Location: India
|
|
|
|
I really appreciate all of you for replying on this post!!
Hello daveporcelan,
As strange it may sound, the fact is that I had to come to this forum for responses after speaking to seniors around me from whom I got mixed responses on this query. |
|
Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006 Posts: 792 Location: Pennsylvania
|
|
|
|
It does seem strange.
What is not strange, is nobody on this board actually gave you a strait answer. Nobody here can really understand your circumstances, so the answer is always 'it depends'.
You can take from this thread whatever helps you get your situation resolved. |
|
Back to top |
|
|
rakesh1155
New User
Joined: 21 Jan 2009 Posts: 84 Location: India
|
|
|
|
What I understand is 'it always depends'.
But I do understand that if its once in a while situation to do some rework (and letting some of your work go waste), it is fine.
But if its a regular thing in such situations, there's surely something wrong.
The conclusion is "at some places, the developer's time and effort hasn't got any value"
Anyways, thanks for your reply daveporcelan !! |
|
Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011 Posts: 556 Location: USA
|
|
|
|
Write the code changes so that they can turn on req 2 with a parm card of some sort. Then test them both at the same time.
Move combined code to prod with the parm set to disable req 2. When it's time for req 2, change the parm card.
I know that it's not that simple to implement in real life, but the concept is sound. |
|
Back to top |
|
|
|