Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am working on a project that is basically a rewrite of an old batch based system that now should run online. The old system is complex and poorly documented and best source of information are people that originally built it and maintained it.

However, even they are often at odds about certain functionalities. What’s worse, they don’t get along very well between them or with the team, since the roles are not very clear, they are considered Product Owners, but feel that they should lead the project.

I wonder what would be the best way to extract the information they possess. At this point I think (and I never thought I’d say that) that face-to-face meetings are not very productive.

Maybe a tool that would implement a flow where they would all have to answer a question that team has would be appropriate. Or maybe a wiki? What would you propose?

share|improve this question
1  
Sometimes it is better to just re-write the system and have the new system do what the business needs today rather than work on the old system that may or may not do what the developers thought the business needed back when they started. –  JonnyBoats Dec 24 '11 at 1:06
1  
@Jonny -- you must have read this and recognized it as satire. –  Jay Elston Dec 24 '11 at 2:43
    
What country is this? –  user1249 Dec 24 '11 at 3:08

4 Answers 4

Don't expect that a technical solution can solve your organizational problems - I have almost never seen that work.

If the roles and responsibilities are not clear, you will have to work that out first, otherwise you risk the whole project becoming a disaster.

What about the people who build the original system - do at least some of them work as developers in your team, helping to build the new system? That would be a big help.

Another thing is that you said "best source of information are people that originally built it" - what about the the old system itself? I guess there are important details buried in there which keep the system alive, but even the original creators have forgotten. So what about using the sources of the old system as the source of information?

share|improve this answer
    
People who build the original system (now POs) don't work as developers, they have been promoted and have not updated their skill set. Old system is used to dig for information, but it is often not clear what business significance some code has. –  Dan Dec 23 '11 at 23:03
    
@Dan: you did not tell us what your role is in that project. And it would be interesting how big the old system is (roughly in lines-of-code). And what is your team size, and the number of "Product Owners"? –  Doc Brown Dec 24 '11 at 14:18
    
I'm just coming on board as an agile consultant since they realized that somithing is going wrong. I haven't seen the original code-base, but it is huge, probably 1000KLOCs –  Dan Dec 24 '11 at 15:24
    
@Dan: IMHO what you need is for each team/product is one person who has understood the requirements very well and who is part of the development team; someone who can "translate" the requirements to the team and understands the technology that will be used for the new system. I would suggest to find someone for that role, perhaps someone with good enough communication skills to get the information needed from the old developers. –  Doc Brown Dec 24 '11 at 23:08

they are considered Product Owners

That's a serious problem. There can be only one. Someone is product owner, everyone else is a Subject Matter Expert. If you can't get this sorted out, you can't make much progress.

Maybe a tool that would implement a flow where they would all have to answer a question...

Perhaps.

Better is this.

  1. Get actual inputs and outputs from the legacy system.

  2. Ask questions about functionality separately. It doesn't matter if the experts agree with each other. Someone has to agree with the actual files. Everyone else can disagree. It's okay if they don't agree with the actual files; ignore their input.

  3. Write unittest test cases based on the actual files plus input from the experts. Include erroneous statements from the experts as comments. It doesn't hurt to collect extra data. However. Discount answers that disagree with actual observable, documented, tangible facts.

share|improve this answer

As said by @Doc and @S.Lot, sort out who is responisable for what first - who is the customer, who is the product owner, who is the achetect etc....... Don't expect any successful progress until this is done. Best not start if you cannot sort this out.

Are you seriously using legacy codes for the project requiements, legacy code is littered with (often obscure) coverage of usually obscure requiments and edge cases, much it no longer relivent to the current state of the product, and much of it still very relivent in uninteligiable ways. Using existing legacy code (and its behaviour) to establish and define customer requirements is foolhardy at best. By all means use it to verify and challange customer requirments but it should not be the definition of them.

I would challange why are you rewriting the product? Many articles have been written as to the commercial reality of software rewrites, wiht plenty of case studies. I suggest reading a few before going much further.

BTW : Harse reality check : Do you know the concept of fail early/fast? If not, I recommend you learn it, as my guess is you will need it.

share|improve this answer
    
This is a transaction processing system. It has to replace the old, but it will be online instead of old batch. It has to generate exactly the same I/O. –  Dan Dec 24 '11 at 1:43

Maybe a tool that would implement a flow where they would all have to answer a question that team has would be appropriate. Or maybe a wiki? What would you propose?

If they are not cooperating face-to-face, a wiki might not be much help. A wiki is maintained by about 1% of the participants in it.

For you project, determine who the actual stakeholders are. These consist of people and organizations that are affected by a system (almost always in a way that can be measured by cost and benefit). The stakeholders determine the business need for the system. They are the ones who need to get together and support a system or not. If they are not together, then the project has a much lower likelihood of succeeding.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.