[RodgerB]

I don't even really have a position in the industry yet, but I am certainly interested in going places with it. But what practices does your employer expect you to do when creating your application?

At the moment, my I.T teacher has got me making a list of steps to create the program, making me fill out a Gantt chart and Journal everyday, creating user documentation and creating the program all at the same time, claiming this is what it is really like in the industry, and in most cases you get paid more for the better planning and documentation included with the project.

Don't make it look like I am coming from the angle, I don't find planning and brainstorming a waste of time at all, infact it is a vital part of any project, but are you constantly told to create a journal of what you did on that day, despite the fact it could take a toll on programming efficiency, and creation of the program?

Let me know what your work ethic is like.

[1lacca]

It is a toll on programming efficiency, because you do something else other than programming. However your employer needs it so he can see how much time did it take to accomplish a task. So the next time you'll do something similar, he will have a better esimate for the time thus he'll be able to better plan resource allocation. It 's simply like this. Also, software development quality assurance standards usually require this kind of self monitoring, because they try to ensure this way, that a firm which gives you a deadline will be able to keep itself to it. Also, the analysis, design, implementation, deployment phases all make sense if you write a bigger program, but there are a couple of methods and they use these phases differently (some will try to create the whole application at once, some will iterate it starting from a prototype with basic functionality and build on it every cycle, but it will always have a working backbone).
As for the other part of your question: yes, these kind of things are really used, the bigger the company the more important they get. Small 1-2 person start-ups won't have time for it, and they will be happy to finish their project, and usually they won't need such coordination (exceptions do apply here). Once they want to get more serious contracts, they will need a quality assurance certification, and since then they'll require you to log your work in some way. Once you work for a multi, they'll have separate departments and people payed to bug you with such things.

[baavgai]

All management enjoys seeing pretty pictures that make them feel they understand what's going on. They wont understand how the program works, that's not their job. They'll understand that work is being done and that timelines are being met; that is their job.

Real programmers program. Time management, documentation, etc, are always secondary to nurturing the skill of someone who can actually write code. If the shop is small enough, you'll have to do it all. If it's large enough, with more than one programmer, you'll very likely have a project project manager type. It's the project manager's job to get dirty with all the planning minutia.

Management doesn't want to talk to real programmers, they're kind of scary. They talk to Bob the project manager. Sure, he knows some programming, but he not as bad as the guys stick in a back room, don't make wear ties, and throw meat at. It should be noted that Bob will likely get paid a lot more.

Seriously, the extent to which you're involved in project planning will depend entirely on the company culture you find yourself in.

[PsychoCoder]

Ive worked on large teams, and small teams. On the last small team I worked on I was the lead developer, and documentation was indeed required, along with a functional spec sheet if time allowed. These kinds of documents prove invaluable, it allows the BA's to explain the time line and how exactly the program works to non IT personnel, and it also gives a starting point for your QA Team.

Now that I work on a large team (well only 10 developers with another 2 being interviewed) documentation is essential. Our PM goes to all the planning and outline phase meetings, but as the application progresses the individual developers are responsible for providing documentation on their functionality requirements, and a functional specifications doc once the application is released into production. We, every member of the Development Team, fully buy into this new theory of software application, the documentation and functional spec doc for several reasons:

• Documentation lessens the time needed for a newly hire developer to get his feet wet in a system, thus allowing him to be productive faster.
  
• Functional Specifications document allows the BA to hand the QA team an outline of how the application, or newly added functionality is supposed to operate, allowing them test the Happy Path first, then move onto breaking it if possible.

Since we started this methodology a few months back the # of bugs caught before promotion to the live environment has drastically lowered, the # of QFE's (Our version of a critical fix) we put out each month has been cut by 1/2. Yes the average time line for delivering a new application, or a new set of tools in an existing application has grown, usually by the same amount of time that the documentation and functional documents take to create and approve, but in the long run all departments are more happy as they know they're getting a better product in the long run.

Not all companies follow these same methodologies, which is fine, Im not saying that the methodology that we use is the only one or the best one. I think each organization needs to tinker with several methodologies, mix and match, until they find one that works for them.

Soon things will be changing at my workplace one again, we're (slowly albeit) starting to introduce the Agile Scrum Methodology of Software Development, if you haven't read anything on this methodology I highly suggest you do, more and more companies are looking at this as a definite possibility for their organization.

I guess in all that writing what I'm trying to get across is this; Don't go into a development job and buck the system they have in place because you feel Part A, or Part C may be a waste of time. Chances are they have spent some time researching the methodology they currently use, and use it for a reason. Go with the flow, follow their methodologies, and if you find a path that can save a few steps along the way, maybe sit down with you PM and point this out, most PM's and IT departments aren't so rigid as to say they're methodologies are set in stone, as they know doing this would eventually end to their undoing

[no2pencil]

My current employer hired me for my Linux Administration & Networking skills, yet most of the day I'm writing VBScript & FoxPro.


So be ready for anything! Can't isn't an option.

[Programmist]

Journal? No. At the end of each day we fill out how may hours we worked on each project in what capacity (planning, code/unit test, debug, etc). It's basically like filling out a time sheet, but hourly and salaried workers alike have to fill it out. It helps management budget, as they are given a specific amount of money per project/release.

[NickDMax]

So, I work really hard on completing a project on time... THEN I get hit with, "Works Great! Where's the documentation?" And so I find myself writing... and wishing that I had kept better notes while designing, implementing, and debugging my code.

I also spend a good bit of time documenting how I spend my time as well (unfortunately for today there is not a nice code for DIC'ing around -- lucky for me I worked Sunday and have lots of extra hours this week).

There is a lot of metadata that goes along with programming. Your teacher is not off to raise your awareness.