Software Development Process (use cases)

[steppinthrax]

So, I was recently hired as a Software Eng, within a gov contractor. I'm contracting for a federal agency that is developing an Inventory Management system. I understand the software development process, however, I've been here 3 months and all I've been doing is working with a team (daily) to draft use cases (textual, activity, sequence, and test). Based on our req, I see we will be doing this for at least 4 or more months until final development of code.

The last places I've worked I've been very close to the system (directly development) with short documentation on req and testing. We usually very quickly write up some stuff explaining how the system works and the system design, and then we jump to development. My question is this position seems to concentrate on the business process vs. the actual development of code. I'm curious do most companies care about programming ability (how great you can code) or understanding and full execution of the SDLC. I'm asking this because I'm worried when going to the next job companies will laugh at the idea that I spent lots of time writing design documents vs. coding????

 

[AyashiKaibutsu]

Depends on what your hired to do. If your hired to be a code monkey then they care about programming ability. If you're hired to write specs they probably couldn't care less how well you know c++, and it could be somewhere in between.

 

[steppinthrax]

Depends on what your hired to do. If your hired to be a code monkey then they care about programming ability. If you're hired to write specs they probably couldn't care less how well you know c++, and it could be somewhere in between.

But what is most valuable in most companies

code monkey>spec writer and coder

or

spec writer and coder < code monkey

??

 

[torpid]

Seems like it would be pretty valuable to have done both, and it seems likely you will be doing both. I fail to see the issue.

 

[Capt Caveman]

Depends on what your hired to do. If your hired to be a code monkey then they care about programming ability. If you're hired to write specs they probably couldn't care less how well you know c++, and it could be somewhere in between.

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.

 

[Aikouka]

It's better to have a good understanding of how things work, but even then... chances are a different company will use a different process or create some of the objects differently.

I'm really not a fan of the document work... it's pretty brainless, and half the time I'm finding issues with other people's stuff that then impedes my own work. But I don't care though... they pay me the same where I do brainless document work or intensive coding .

I do wonder if there's a point where too much time is spent working on documentation that it's more like "over-documenting." It reminds me of when I was at my previous job and they wanted me to write some document on this application. Well, I wrote it and apparently, even though I included all of the necessary information... it wasn't enough. They wanted pretty much everything and anything! They say the number one rule of writing is to know your audience... I guess someone should've told me that my audience was a kindergarten class .

 

[steppinthrax]

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.

Do most major companies care about

"develop use cases, document business processes and develop a complete set of business and technical requirements before even thinking about coding"

Or

A code monkey

Also in terms of money?

 

[IndyColtsFan]

But what is most valuable in most companies

code monkey>spec writer and coder

or

spec writer and coder < code monkey

??

In most companies I've worked at, the most valued employees are the ones that can do both well. If I had to pick one "side" or the other, I think most companies favor the soft skills -- project management, being able to sit with your customer to iron out the requirements and specs of the project, etc. I'm interested in hearing other opinions for sure, though.

 

[steppinthrax]

In most companies I've worked at, the most valued employees are the ones that can do both well. If I had to pick one "side" or the other, I think most companies favor the soft skills -- project management, being able to sit with your customer to iron out the requirements and specs of the project, etc. I'm interested in hearing other opinions for sure, though.

I"ve had some job interviews where all they asked were a bunch of programming related questions, then I had some that concentrated on the "soft stuff".

 

[Aikouka]

Do most major companies care about

"develop use cases, document business processes and develop a complete set of business and technical requirements before even thinking about coding"

Or

A code monkey

Also in terms of money?

In my experience, if you're hired as a software engineer, you're expected to be flexible in the task you'll perform whether it's design or implementation. They don't always expect you to know a ton of information about the design process or even the programming language. I've learned most of the design process that I'm using now while working.

EDIT:

I"ve had some job interviews where all they asked were a bunch of programming related questions, then I had some that concentrated on the "soft stuff".

Some of their questions may depend on the interviewer or the job posting. If the posting mentions "intimate knowledge of C#", chances are they may ask you C# questions to help gauge your skill level with it. Sometimes they get a feel of your development cycle knowledge by just asking about previous projects. Questions like when you started the program (in the beginning, middle, end) and such can usually give a good feel for those.

 

[IndyColtsFan]

Do most major companies care about

"develop use cases, document business processes and develop a complete set of business and technical requirements before even thinking about coding"

As the other guys have said, depends on the company and what you were hired to do. Some companies employ dedicated business analysts who document the business process and iron out the business requirements and then have dedicated project managers who manage the whole project (schedule, deliverables, budget, etc). Others combine the roles into the same position, which is where I am at. I generally perform the role of business analyst, programmer/developer, and project manager.

 

[Capt Caveman]

Do most major companies care about

"develop use cases, document business processes and develop a complete set of business and technical requirements before even thinking about coding"

Or

A code monkey

Also in terms of money?

Are you this dense? I can hire an overseas code monkey to do my coding, having someone that knows a company's business processes, system integrations, etc. is invaluable. Knowing this and coding takes you up the ranks where the money is.

Doesn't sound like you understand a SDLC at all.

 

[IndyColtsFan]

I"ve had some job interviews where all they asked were a bunch of programming related questions, then I had some that concentrated on the "soft stuff".

The logic is that technical skills can be taught fairly easily, whereas soft skills are much harder to train. If you have someone who knows the technology and has great soft skills, that's a great combination.

 

[dwell]

No time for the SDLC where I work. Agile, baby.

 

[sdifox]

You must know how to code, not necessarily the latest language or what have you nots, but a deep understanding of how things make sense when you code.

That gives you a good basis to design systems and be efficient on delivery.

I no longer code, it is not cost effective for me to code. I offshore the coding. But I am the solution designer. I work with the clients and immerse myself in their business, understand what they want to do, where they are and where they aught to be.

 

[steppinthrax]

I understand now.

 

[brianmanahan]

Doesn't sound like you understand a SDLC at all.

most SDLCs are retardedly complex processes that slow everything down, create a bunch of worthless documents nobody is going to consume, and give some inept people a position.

not that having a process is bad, its just that most processes should be about 5% of the size they actually are.

and RUP can diaf

 

[paulney]

SDLC? The nineties called, they want their dinosaurs back. Unless you work for a giant like IBM or Cisco or a government contractor for the military dev, where you do indeed spend most of your time with baldening overweight middle aged men sipping coffee, toting their fanny packs and updating the design docs, you would do much better getting hands on experience with the latest technologies.

Are processes important? Yes, to a certain degree. Will you get a position in a hot new startup with baggage like this? Very unlikely.

 

[IHateMyJob2004]

Do most major companies care about

"develop use cases, document business processes and develop a complete set of business and technical requirements before even thinking about coding"

Or

A code monkey

Also in terms of money?

I work at a defense contractor with 8000 employees (one site). I used to do embedded systems work and the crap you have as deliverables is ridiculous. Use cases, sequence diagrams. All that crap. And the thing that really sucked is how much time we spent "polishing the turd". The turd being the documents. In the end, projects were always late and of no higher quality. Oh, we did waterfall.

In the same company I changed to an ITish department. First job was software for aircraft carriers using an agile process that met all the same requirements. We had thinner documentation, were on time and under budget. And the software actually worked!

It's sad how much time is wasted on design documents and detailed SRS requirements. I am good enough at my job now that I have yet run into code that needs up front design. If you understand design patterns, your code is self documenting. As a a matter of fact, our application mentioned in the above paragraph had very good javadoc and was thusly self documented. had customer buy in on this by the way. All that was needed was a very thin top level design document that was done AFTER the code was done. So we didn't have to deal with fixing the incorrect design document later via a convoluted process.

So, waterfall. it sucks. it is not needed. That is the failure of my old department that is constantly overbudget and late. I once spent 4 months fixing commas and other meaningless crap in an SRS. That was the last straw for that department.

As for more recent work, we used agile development as a CMMI level 3 site. And everything was to CMMI standards. People that think this is not possible simply do not understand modern methodologies. CMMI does not mean waterfall.

waterfall, how software was done in the 80s. It is imnportant to know more than one process by the way. I am not an agile nazi. there is no one process that works. But you need to know how to create a process that works. That is the correct process. To create though, you need to understand idealized models that are not real world usable for all scenarios.

end rant.

 

[Merithynos]

No time for the SDLC where I work. Agile, baby.

Ah, "Agile". In my company that's translated as, "we don't need to give you final requirements until three days before you're planning to install, but it's your fault that you couldn't complete development in time, oh and by the way, why didn't you give me enough time to test the finished product?"

 

[IHateMyJob2004]

In most companies I've worked at, the most valued employees are the ones that can do both well. If I had to pick one "side" or the other, I think most companies favor the soft skills -- project management, being able to sit with your customer to iron out the requirements and specs of the project, etc. I'm interested in hearing other opinions for sure, though.

Most customers know 90&#37; of what they want. it is not worth spending time and money up front figuring out the other 10%. 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.

A good project lead can make the customer happy and be on time and on budget and be flexible. based on my previous comment, our project is actually held in high regards at our governmental client (can't say to much). This one gov't facility though is probably 1000+ people. And our team of 4-6 people did work that is held in very high regard there.

 

[Aikouka]

I work at a defense contractor with 8000 employees (one site). I used to do embedded systems work and the crap you have as deliverables is ridiculous. Use cases, sequence diagrams. All that crap. And the thing that really sucked is how much time we spent "polishing the turd". The turd being the documents. In the end, projects were always late and of no higher quality. Oh, we did waterfall.

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 .

 

[Ghiddy]

SDLC? The nineties called, they want their dinosaurs back. Unless you work for a giant like IBM or Cisco or a government contractor for the military dev, where you do indeed spend most of your time with balding overweight middle aged men sipping coffee, toting their fanny packs and updating the design docs, you would do much better getting hands on experience with the latest technologies.

Are processes important? Yes, to a certain degree. Will you get a position in a hot new start-up with baggage like this? Very unlikely.

This. Companies that spend too much time on designs and requirements never get anywhere. In some cases it makes sense, if you are doing hardcore engineering. But Enterprise type development doesn't need it. Most companies I've interacted with or worked in on the enterprise side could stand to cut out about 50% or more of their technology cost my reducing bloat in the form of this crap. I had to do several projects where I worked with an external company and it drove me crazy to join their meetings. Endless #'s of Indian programmers jerking off each others' bureaucracy peens on weekly, daily, hourly, and minute by minute conference calls. They divide everything into narrowly focused teams, and access to anything is strictly metered to in miniscule amounts. I could literally accomplish the work of everyone on the phone call (database, web, sysadmins, software architects, code monkeys, project managers, etc -- i've had extensive experience in all these roles), but because everything is so controlled and red-tape focused it takes weeks and at least a dozen people to get even a simple task done.

My take on it is that in theory all that process stuff is good as long as it doesn't get in the way of the real priority, which is achiving business value. You have a lot of people hiding behind the processes to hold up work for some combination of laziness, ego, self promotion (shoot down everyone else's stuff, and hold back any efforts that don't benefit you). Agile is the way to go and barring the hardcore engineering firms, places that are process heavy are so 1990 as an above poster already stated.

On the other hand people in my own organization suffer from the opposite problem. I'm the only one with "real" experience, and my boss has no clue about how to run a tech team yet insists on being hands on for that aspect, basically reducing me from a director to a software grunt 90% of the time. 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. No one documents anything or follows any kind of software best practices. I get called in to fix all the messes this causes.

 

[Modelworks]

So, I was recently hired as a Software Eng, within a gov contractor. I'm contracting for a federal agency that is developing an Inventory Management system.

Stay far away jobs related to the above if you don't like what you are currently having to do, it is why I stopped doing anything government related. The jokes about government red tape are not made up and it applies to everything from people that write code to the people that staple papers. Corporations can be bad about the things required but government adds a whole another layer on that.

I was once told that the purpose of documenting government work was to produce so much paper that if anything goes wrong the number of documents will allow anyone to claim what they want because nobody wants to sort through it all to find out the truth.

 

[Codewiz]

Stay far away jobs related to the above if you don't like what you are currently having to do, it is why I stopped doing anything government related. The jokes about government red tape are not made up and it applies to everything from people that write code to the people that staple papers. Corporations can be bad about the things required but government adds a whole another layer on that.

I was once told that the purpose of documenting government work was to produce so much paper that if anything goes wrong the number of documents will allow anyone to claim what they want because nobody wants to sort through it all to find out the truth.

Well that is slowly changing. For instance, I work on a project where we use agile methodology. This is for the government. We have 2 week sprints and there isn't a bunch of documentation outside of user stories, requirements, and O&M.

But in general, yes you are correct.