Software Development Process (use cases)

[IHateMyJob2004]

I know what you mean. The problem is that's because people keep using previous programs as their prime example of what to do. "Hey, when I was on program_name_here, we did this and it worked!" I hear that kind of thing all the time... it's no wonder they keep using old models ripe with worthless documentation that doesn't help anyone.

I almost wonder if younger engineers are more willing to use something such as Agile over Waterfall. It might make sense given the majority of program managers I run into probably remember when Waterfall first came about in the 70s .

Waterfall was a big step in software development processes. it improved over the no-process methdoology ;-) To think, computer tech may have changed since 1970?

Another issue is trying to get support from your manager to use anything other than waterfall. They don't know anything other than waterfall (typically) and refuse to learn anything new.

Want to have some fun? Look at this list and see how it applies to your company:
http://en.wikipedia.org/wiki/List_of_cognitive_biases

 

[IndyColtsFan]

Most customers know 90% of what they want. it is not worth spending time and money up front figuring out the other 10%.

Maybe where you work, but I'm alarmed at the people who request new systems and when you meet with them, have NO clue what they really want.

Get the major functionality working and during that time, iron out some of that 10%. Show them some of that 10% and get feedback. And repeat.

Oh, I agree 100% -- I use an iterative process where I meet with the requestor once or twice to nail down the major basic functions/specifications of the software, build it, and then meet again to go over what I've done and any additional tweaks/functionality they'd like to see. This is a give and take process and can last weeks to a few months on larger projects. What you have to be careful of is scope creep, and that's why I always ask in the first meeting what the target date is and then I will tell them what I can and cannot have done by that date. We have no real project management process here so the user is going to get what he/she wants regardless, but I have to do my best to manage expectations.

I'm studying for my PMP right now and I'll be completely, 100% honest about it -- half of the material is rubbish. For example, I was studying chapter 10 (communications) last night and watching a training video about the topic. The said we need to memorize the formula to calculate "communication channels" in our project team. Ok, how many project managers sit down in real life and say "Ok, I've got 10 team members so I need to calculate the number of communication channels in my team." Seriously? And the whole notion of having to memorize something like 50 formulas for the test is another ludicrous example. I'm getting the PMP because it is really respected in various industries and will probably help me command a higher salary, but I'm the first to acknowledge that a significant portion of the material is of very questionable value.

Also, while I haven't read through all of the threads here, I think many people are missing a key point of documentation. Yes, you can definitely go overboard with documentation (I think most PMs do). How many of you guys have worked in IT departments where you have multiple people doing your job and one of those people just leaves? How many times have you had to spend a significant amount of time reverse-engineering their work or cleaning up messes? In these situations, how many times have you wished "Damn, I wish I had a small document outlining this project"?

 

[dwell]

I agree the SDLC is useless for most projects. If you're building a defense system that will be in use for decades, alright, it makes sense. Most of the code we write won't be in use in two years, much less a decade.

I hate it when some group forces me to write a specification just to stall efforts because their side is not ready. I've written hundreds of pages that were glanced at once by some figurehead then rots in a document repo, untouched since. I look at any of the documents I wrote two years ago, and hardly anything is applicable today.

I know it depends on what you're doing, but what I do is easy enough for anyone to understand with a 10 pager. We have groups in India, Sweden, and the UK writing code off of nothing but an API documentation wiki and it's been nothing but a success.

The only key document is the functional requirements, which some BA handles. We get the users to sign off on it before we start writing code. This includes open issues and loose ends.

 

[DesiPower]

They are using archaic methods of software development, also know as SDLC, looks like waterfall. These days everyone used Agile/Scrum, specially while using contracting companies. Method mentioned in OP has more chances of being doomed...

 

[Elbryn]

I'm studying for my PMP right now and I'll be completely, 100% honest about it -- half of the material is rubbish. For example, I was studying chapter 10 (communications) last night and watching a training video about the topic. The said we need to memorize the formula to calculate "communication channels" in our project team. Ok, how many project managers sit down in real life and say "Ok, I've got 10 team members so I need to calculate the number of communication channels in my team." Seriously? And the whole notion of having to memorize something like 50 formulas for the test is another ludicrous example. I'm getting the PMP because it is really respected in various industries and will probably help me command a higher salary, but I'm the first to acknowledge that a significant portion of the material is of very questionable value.

Also, while I haven't read through all of the threads here, I think many people are missing a key point of documentation. Yes, you can definitely go overboard with documentation (I think most PMs do). How many of you guys have worked in IT departments where you have multiple people doing your job and one of those people just leaves? How many times have you had to spend a significant amount of time reverse-engineering their work or cleaning up messes? In these situations, how many times have you wished "Damn, I wish I had a small document outlining this project"?

on the pmp thing, it's a way of formalizing a framework for managing something that inherently is unorganized. just another tool just like sdlc, agile, six sigma, or lean. the problem is too many folks who have gone through those types of training either try to apply them as an out of the box, trying to fit the square process changes into the circular organization slots. That's how you end up with the fads here and there. smart companies will take those tools and modify them to fit the company culture.

on the pm documentation thing, i feel that's simply in their own self interest to over document. the documentation they create is the only thing they have to defend themselves with should any issues or questions come up. If you're a pm, you would rather over document and over communicate than not do enough and get screwed.

 

[OOBradm]

But what is most valuable in most companies

code monkey>spec writer and coder

or

spec writer and coder < code monkey

??

probably the ability to write non equivalent comparison statements

 

[manlymatt83]

I agree. OP - you accepted a job without knowing what you were going to do? And you need to decide what you want to do with your career to decide if you should be performing more coding.
Two different career paths.

If you don't understand the need to develop use cases, document business processes and develop a complete set of business and technical requirements before even thinking about coding, sounds like you need more experience understanding a SDLC and not just being a coder.

If I remember, aren't you some super hotshot that's smarter and better than all of your coworkers? Makes me wonder why you're even asking, you should know the answer.

Depends what he wants to do. Traditional Waterfall development is outdated for a lot of companies.

http://en.wikipedia.org/wiki/Agile_development
http://en.wikipedia.org/wiki/Lean_Startup

 

[Capt Caveman]

Depends what he wants to do. Traditional Waterfall development is outdated for a lot of companies.

http://en.wikipedia.org/wiki/Agile_development
http://en.wikipedia.org/wiki/Lean_Startup

And if you don't know the business process, capture proper business requirements and know the s(system)dlc of the product, the sdc method is moot.

 

[Aikouka]

I have to hound people to check in their code, we have no QA process whatsoever, so I spend at least 30% of my time looking over other peoples' code.

What about when people check in code with a blank comment? That's usually fun to deal with when you need to find out what they actually did or roll back a change.

 

[IndyColtsFan]

on the pmp thing, it's a way of formalizing a framework for managing something that inherently is unorganized. just another tool just like sdlc, agile, six sigma, or lean. the problem is too many folks who have gone through those types of training either try to apply them as an out of the box, trying to fit the square process changes into the circular organization slots. That's how you end up with the fads here and there. smart companies will take those tools and modify them to fit the company culture.

That's the key. You have to be able to intelligently apply the tools/processes to your work and not jam everything into the framework even if it isn't a good fit. There are definitely some good ideas in the methodology but there are also some ideas which are extremely questionable (like the aforementioned "you need to know how to calculate the number of communication channels in your project team!"). At any rate, while I will memorize all the formulas to pass the test, PMI needs to enter the 90s and realize that formula memorization is a terrible waste of time and resources.

on the pm documentation thing, i feel that's simply in their own self interest to over document. the documentation they create is the only thing they have to defend themselves with should any issues or questions come up. If you're a pm, you would rather over document and over communicate than not do enough and get screwed.

Exactly.