|
I am very surprised that the lowest is that the project be fully documented. Wow! An application doesn't have to have the best design or be completely error free if the application is fully documented. Plus, the fact that the people maintaining the application will probably not be the same people that develop it. I don't care how well designed an application is. If no one knows how it works after you are gone it is useless the first update that is asked to be done or the first break fix that needs to take place.
|
|
|
|
|
I am not surprised at all but I write nearly 100% of my code for in house projects used for medical imaging research. So the 500,000+ lines of new code (not copy/paste) I have written in the last 10 years most of it is not documented more than having sensible names for variables and methods. This probably will change when I hire a second programmer (in the process of that right now) to help me with my stuff as any more and this is way too much work for a single person...
John
|
|
|
|
|
Hi All,
I use VS2005,Excel2003,WinXP-sp2 and create asp.net web application project to open the excel file.
I want to show excel application.
If I use visual development server type from project propertes,I get it.
But if I use IIS Web server type ,I can't get.
How can i get to open excel application by web page?
I want to use by IIS Web Server option type.
Some codes:
Excel.Application excelApp = new Excel.ApplicationClass();
excelApp.Visible = true;
Excel.Workbook newWorkbook = excelApp.Workbooks.Add(XlWBATemplate.xlWBATWorksheet);
string workbookPath = "C:/text.xls"; Excel.Workbook excelWorkbook = excelApp.Workbooks.Open(workbookPath, 0,
true, 5, "", "", true, Excel.XlPlatform.xlWindows, "", true,
true, 0, true, true, true);
Pls Reply ,
Thanks in advance.
Keluar
-- modified at 20:59 Thursday 4th October, 2007
|
|
|
|
|
Correct me if I am wrong, as I tend to be on many things, but isn't this in the wrong area?
S.Nowlin
-----------------------
The journey is straight, it's the path that is twisted. Oh and did you hear? There is no spoon, only sporks.
|
|
|
|
|
hi,
i guess i'm lazy, i want to reach my target doing as less as i can. A less code as possible but doing what it needs to do. Such things results in happy boss, short time, low cost, etc....
And documentation should be delivered before starting to programming.
greetz
Kurt
|
|
|
|
|
topcatalpha wrote: documentation should be delivered before starting to programming
That may be your opinion - it certainly isn't mine!
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
I agree with you!
I have only worked on single person project (application wise). Any documentation before was supplied specs and temporary outlines that I created base on my research (if any). Otherwise documentation was created during or after or after the programming phase. I keep a daily log of what I did and why.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Happy Boss!! Dont tell that. If our part is done well, Boss will appreciate. If he does not, then he is not fit for the post. Why worry about the Boss then?
------------------------------------------------------------
"The only true wisdom is in knowing you know nothing." --Socrates
|
|
|
|
|
I've only worked at one place that had their documentation before hand. It was great in that everybody knew what to expect from the program.
Every place I've worked since then has had the motto of: We'll document what we did when we find the time, meaning never. Makes for some interesting conversations. "Why is this screen laid out like this? Let me check the document..... crap! OK, what would you like it to look like?"
|
|
|
|
|
Well i have to agree that getting finished docs before programming is wishfull thinking..
greetz
|
|
|
|
|
Documentation is a no, nobody everyreads it and it's out of date the moment it's created.
Documentation is a time waster unless it's for a schrink wrapped product.
Chuck Norris counted to infinity - twice.
|
|
|
|
|
I guess it depends on the kind of documentation your shooting for. Documenting code object models or DB diagrams is pretty much garbage to the end user.
However, I think documenting the user interface so that the user knows what the program should be doing when they hit a button or start an operation is a very good thing. This can be quick and as simple as "Button saves all data on the screen. Sales report will be printed for date blah blah blah."
When I've been on projects that did this the users actually looked at the documentation to learn how to use the program and would check their assumptions against it before they called us to report any issues. The other bonus is that UI specs can help prevent scope creep. "Does the documentation you signed off on say the program will do X? No? Then that's an addendum that will need to be paid for separately."
I've seen the benefits in this and would prefer all my projects started this way.
Chuck Norris doesn't tea bag people, he potato sacks them.
|
|
|
|
|
My usual rule of thumb is that if the code works then it's a winner. That usually means NOT paying too much attention to the letter of the original spec. It also means that timing and budget are lower priorities. A client/customer can usually be persuaded to pay for a project if and when it works properly even if it's cost more and taken longer than planned and even if it doesn't match the original spec(because the spec was wrong). They are much less likely to pay up happily for one that was made on budget, on time, matching the spec but doesn't work!
Quality of design and implementation are always high priority.
That's what's usually right in my circumstances but in other circumstances things may be very different. For example, it's sometimes vital to get a product to market before the competition or to meet a specific timed need. Then a hastily thrown-together jumble of code that does something vaguely right may be better than nothing at all. I never work like that (I would hate it!) but some people do - sometimes it may even be justifiable.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
As a documentation specialist this survey makes me feel so unloved!
Oh well
S.Nowlin
-----------------------
The journey is straight, it's the path that is twisted. Oh and did you hear? There is no spoon, only sporks.
|
|
|
|
|
It's not you that's unloved - it's the task of documentation.
Most developers recognise the importance of documentation but hate having to do it. I would hope, therefore, that they would welcome having a tame documentation specialist to do it for them. (You are tame, aren't you?)
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
Well, you have to 'splain your definition of "tame".
Me friends says I'm wild and crazy, but work-wise I'm very diligent.
I'm not meek by any means.
S.Nowlin
-----------------------
The journey is straight, it's the path that is twisted. Oh and did you hear? There is no spoon, only sporks.
|
|
|
|
|
The number of times I could have used someone like you makes me sick. Working alone my answer to upfront documentation or creation during development, was usually something like “do you need the documentation or do you want it finished on time?”
Once time after the project application was complete and ready to go, I said now I can do all that documentation (as I had planned for). The answer was no, we need you to work on this other project now. Very frustrating as I was looking forward to a change of pace; oh well.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I freelance!!!
S.Nowlin
-----------------------
The journey is straight, it's the path that is twisted. Oh and did you hear? There is no spoon, only sporks.
|
|
|
|
|
am I using CListCtrl? If I'm not, the likelihood of completing the job in a reasonable and sane time frame is probably not within the problem domain that you've set for yourself. On the other hand, it might be simpler to go out, have a few beers with your buddies, and just contemplate Chuck Norris counting to infinity.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
How often would the boss/client be happy, if the job matched the initial spec ?
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Very rarely I suspect. That is why it is often a moving target.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
What makes the Boss happy and what makes the Client happy are usually at odds with each other. The Boss usually wants the projects done on time and under budget. The Client usually wants all their features, plus a few more that they just thought up a day before the deadline. As scope starts to creep as it often does there is a fine line to be walked. An extra feature can normally be put in here or there when time is left over, but if hours are tight the client starts to hear "No" when they ask for changes.
The boss will be happy you said no to new features or changes but the clients won't be.
The extent that this becomes an issue is based on the company you work for in my experience. I've seen both extremes. I worked for one company that would gladly burn clients at the stake as long as we got paid. I've also worked for a company that would loose money on a client just to make sure they were happy in the end.
As a employee who likes to receive paychecks I make sure the boss is happy first.
|
|
|
|
|
What a pedantic lot you all are
regards,
Paul Watson
Ireland & South Africa
Andy Brummer wrote: Watson's law:
As an online discussion of cars grows longer, the probability of a comparison involving the Bugatti Veyron approaches one.
|
|
|
|
|
thrakazog wrote: As a employee who likes to receive paychecks I make sure the boss is happy first.
I'm my own boss - if my client is happy then I'm happy.
In my case, I voted 5 for this one.
|
|
|
|
|
Come on guys, when is the boss ever happy
Why is it when you are busy everyone whats it yesterday, But when your not no-one has any work for you?
|
|
|
|