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've just started my first IT job in a team with two developers (junior and senior), a project leader and an architect. My role is not yet completely defined and I said I'd be ok with both programming or testing. For now they put me on use case analysis since the PL says that it would leverage my analytical skills (I'm a science phd).

Now the question is who's usually responsible for use case analysis? How usual is it to put a newbie on it?

The hidden fear I have is: are they trying to keep me away from programming (after two weeks I still haven't SEEN a line of code...)?

share|improve this question
    
If you're interested in doing actual code work, I'd suggest (after you've done some analysis and maybe have some down time) you ask one of the other developers if there are any features that you could work on coding, in addition to the analysis. –  Wayne Werner Dec 23 '11 at 17:21
    
are they trying to keep me away from programming (after two weeks I still haven't SEEN a line of code...) Computer programming is the process of designing, writing, testing, debugging, and maintaining the source code of computer programs. Use cases are part of programming. And it's a lot more useful for noobs to be involved with the design aspects before they get involved with actual code (imho). Code is the final product of the process, you need a lot of stuff before you get there. Code may be the most exciting part of the process, but don't rush yourself, or you'll fail miserably. –  Yannis Rizos Dec 24 '11 at 0:25

4 Answers 4

up vote 7 down vote accepted

who's usually responsible for use case analysis?

Everyone.

How usual is it to put a newbie on it?

Not too unusual. You may have appropriate problem domain knowledge that makes you more valuable working with the users.

The hidden fear I have is: are they trying to keep me away from programming (after two weeks I still haven't SEEN a line of code...)?

Yes. They secretly want to destroy you.

No. You've only been there a short time.

share|improve this answer
    
About the hidden fear: I'm not really that paranoid, but it's just a thought that crossed my mind... Thanks anyway :-) –  inovaovao Dec 23 '11 at 16:53
2  
"I'm not really that paranoid". You brought it up. Therefore, it obviously concerns you. –  S.Lott Dec 23 '11 at 17:00

Were you hired as a software developer? It doesn't sound like it to me.

You said your role is not completely defined. This means they can ask you to do almost anything that is realistically related to IT. This includes analysis work. And, if they want to leverage your analytical skills, it sounds like you might be doing more analysis work than actually writing code.

I don't think it's unusual at all to put a development newbie on analysis work, since you are clearly not a newbie at that, given your Phd in the sciences.

I've been writing software for 20+ years. I've done my share of analysis work, and I've worked for companies where the 'Analysts' do this sort of thing.

share|improve this answer
1  
... and I have worked for companies where the Analysts are supposed to do this sort of thing, but they were awful so the developers did their share of analysis work ;) –  maple_shaft Dec 23 '11 at 17:42

A few more thoughts:

who's usually responsible for use case analysis?

It depends. On a small team, often everyone. I've also seen cases where the answer is

  • problem domain experts who don't write code

  • senior engineers - so the problem is defined by someone with experienced judgement

  • junior engineers - as a vehicle for getting their feet wet and communicating about the goals, the problems and the solutions before anyone runs too far down the road into implementation.

Another question might be - is it reasonable for anyone to be doing use case analysis right now. It's "make work" if you already have a decent set of use cases sitting around that need to be implemented. It's not make work if the team either (1) doesn't have a set of decent use cases, (2) is about to start a next release and doesn't have cases for that release.

How usual is it to put a newbie on it?

Not too unusual. You may have appropriate problem domain knowledge that makes you more valuable working with the users.

I agree with S. Lott on this.

The hidden fear I have is: are they trying to keep me away from programming (after two weeks I still haven't SEEN a line of code...)?

Two weeks is early for that particular concern to be justifiable.

A few other questions to ask yourself (or your manager):

  • what does it take to see the code? Can you just look at it and start learning it? If it takes a special computer, or a special environment, or LAN access or something, it could be that you are doing use cases while the team waits for the buraucracy to do what needs doing.

  • is there someone free who can go through it with you? If not, this may just be a bad time in the cycle for ramping up the new guy, so they have put you in a place where they know you can achieve some good stuff without much help. This is realistic - I can say as a manager, I don't like the idea of just sending off a new guy (however skilled) with no support from an experienced team member. If I have only two people and it's a crunch, I can't spare the 50% of the time that the senior guy will need to break in the new guy. Seriously, it's usually 30-50% of a senior person's time for 2-4 weeks to get a new person up and going. Learning curves are expensive.

I would say, it is unlikely that you need to be concered if - the team in a crunch, you don't have the tools you need, and/or the next release (for which you are writing use cases) is due to start immanently - they have put you ahead of the curve, so you are prepped and ready for a next release.

If you seem to be coming in in a long-term project where no new release is in sight, and no chaos is ensuing from bad use cases, then you may want to have a sit down with your manager in the next week or two and say "so... explain to me why writing use cases is beneficial?" and "couldn't I be more help testing or writing code?". And then a real discussion of his perception of your skills vs. your perception and what you can do to get to the work you'd like to be doing.

share|improve this answer

Use cases usually come from someone who has a large amount of customer interaction, business knowledge, or a proper problem definition - not just the guy who had "the problem" explained to him.

Sticking anyone on Use Case analysis who does not fully understand the nature of the customer's need/complaint/requirements is bound to create a system that is not going to meet those needs/address those complaints or meet those requirements.

I think it is wrong to give Use Case development to anyone who doesn't have the COMPLETE problem/need definition in mind, and that it dooms a project to failure at the very outset.

If you don't have the knowledge that I mentioned, I'd suggest that the assignment must include a person/persons that have such knowledge, even if it will end up being you who codifies this knowledge into the Use Case representation on paper.

share|improve this answer
2  
The OP claims to be a Ph.D so he/she might have specialized domain knowledge that makes him perfect for use case analysis though. –  maple_shaft Dec 23 '11 at 17:43

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.