|
 CListCtrl
I think, that Undo + "Rich Edit Control" + "Visual Basic" is better  .
(See text answers..)
|
|
|
|
|
I admit laughed when I saw "derrive from CListCtrl." I think derriving from CGridControl is much better though.  And no I did not enter an optional answer...
John
|
|
|
|
|
So I put in the File >> New >> Projects..... answer 
In reality - the projects I work on have different starts depending on how well understood the project domain is.
If the project domain is well understood, then requirements are discussed with customers, specifications written, reviewed and eventually signed off, and so forth. This makes up about 2/3 of the work I do.
Some projects are a bit more open ended, and are more illustrations or demos of a technology and what can be done with it (like some GPS/GIS stuff I was working on, and some speech recognition stuff too) in order to get interest from customers. In those cases, it's a bit more ad-hoc and based around what we think would be useful to demostrate (so lots of pretty graphics are good, because people can understand better if there's something visual to look at. The GPS/GIS stuff was good because we could display maps using MapPoint to illustrate various points). In these cases, there aren't any written specs, although there should be some documents on what the software does and it's internals (doesn't always happen).
Or I'm working out how to do the impossible, which just requires Visual C++ and some balls
Ian Darling
"The different versions of the UN*X brand operating system are numbered in a logical sequence: 5, 6, 7, 2, 2.9, 3, 4.0, III, 4.1, V, 4.2, V.2, and 4.3" - Alan Filipski
|
|
|
|
|
Ian Darling wrote:
None of the above apply 100%
I agree. To me it's a combination of 2, 3 and 4...
John
|
|
|
|
|
Where I work, the users (Marketing) are supposed to give us (Engineering) requirements in the form of a <shouting>Marketing Requirements Document</shouting>. The MRD is supposed to describe what new products are supposed to do, and what customer needs they are intended to fill.
In 13 years at this company, the only MRD I've found useful was one sheet of paper, which described what ended up being 22 months of work. The rest of the time, MRD's have been useless or non-existent. I've actually had Marketing people tell me they didn't want to show Engineering the MRD for a product, because they were afraid we'd make them commit to just that set of features.
In the end, the requirements that our design supports are based on casual interaction with individual Marketing drones and our own knowledge of the end customer.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote:
because they were afraid we'd make them commit to just that set of features.
John
|
|
|
|
|
<sarchasm>Your statement really wants me to purchase products from Scitex Digital Printing!
|
|
|
|
|
Actually we do pretty well, considering. Our products are successful, despite the deficiencies in the process. I was lamenting the lack of 'formal consistency', more than anything else.
KevinHall wrote:
Scitex Digital Printing
Not to worry; we're now Kodak Versamark, Inc.[^] To make a long story short, Eastman Kodak sold us in 1992 to Scitex for $70M, and then bought us back last fall for $265M.
Software Zen: delete this;
|
|
|
|
|
As a hobbiest, I only write apps for my self. I may have picked up some bad habits along the way, but when I start a new project, I usually have a vague idea in my head what I want, and I just start coding, developing and refining the apps features as I go along.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
Yeah, and often what the hobbiest creates is the most innovative.
Regardz
Colin J Davies
* WARNING *
This could be addictive
The minion's version of "Catch ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif) "
It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
|
|
|
|
|
The problem is getting into our heads what the users want. When you are the user that problem doesnt exist, but when the user is someone else, or a group of persons, your biggest problem may be to know what they actually need.
I usualy focus on what they need, rather than in what they tell me, for that I try to understand theyr business before doing any design or coding.
Should we do what they ask us to do, regardless of what we know they need, or should do we do what they need, regardless of what they want?
|
|
|
|
|
|
Before starting a project it is neccessary to ascertain what the client||users actually want, not what they say they want.
To do this it's good to find out why they want what they are asking for.
Also what good it will do them and what ramifications it will have for the business.
From this tiny analysis you may start to see the greater picture of what is needed, and commonly it is not actually what the clients||users have actually asked for.
Normally most users will be happy to just get some good usage out of CListCtrl, but as a coder you can make this experience better for them.
Regardz
Colin J Davies
* WARNING *
This could be addictive
The minion's version of "Catch "
It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
|
|
|
|
|
When I work on a "project" (something "large", usually),
I discuss requirement (I try to rephrase requirements in my own
language, and ensure that the client understands my rephrased
version - chances are, I may catch some subtleties this way)
I stop discussing when I have enough of the "big picture" to
understand what the client needs. (even if it's in-house, it
does not matter)
Then I design and plan. I show the results of my planning
to the client.
Sometimes, the client says "it's too expensive - it takes too long".
Then I discuss requirements again, outlining alternatives. "we could
have a basic print in version 1.0 and have all the other options for
printing in next release".
I re-iterate until the client accepts my terms (It will cost $ XX.YY
and or it will be ready YYYY MM DD)
Sometimes, I cheat. When I have to make planning on things that I am
not familiar with, I make a quick and dirty "test app" to get aquinted
with a concept as a programmer, givving me a better idea of how long
it could take to program. (often, I guess. I never spend as long as half
a day for things like that). I don't call that "prototyping", maybe
I should. I never show these to my boss - client. Its just a proof of
concept for myself.
I usually have more design to do after the planning is accepted by
my client (aka boss). I quickly jump in to the code. I usually wait
until an important feature works for real before showing it to
anyone.
|
|
|
|
|
Sure in a perfect world, we'd have all our requirements before we designed and coded. But something usually comes up that our design just can't quite handle, and at least some part needs to be refactored.
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
Get a list of requirements, prioritise them, start designing, then code, 2 weeks later throw code away as user didnt know what they really needed, go round this loop until another job appears on the horizon 
|
|
|
|
|
Okay, it's true some customers are too lazy to properly think out exactly what they want, but supposing in an ideal world where they go to great effort to specify what they want, you will still get at least a few new requirements during development. This is because it's simply impossible to forsee everything ahead of time. Your development process has to be flexable enough to handle this.
|
|
|
|
|
Navin wrote:
we'd have all our requirements before we designed and coded
I have always seen that the reqirements change from meeting to meeting and I design my applications with this in mind. Sometimes its a game trying to predict what the new change will be and already have the ability (maybe even a partial implementation) to add it to the application without much effort.
John
|
|
|
|
|
John M. Drescher wrote:
I have always seen that the reqirements change from meeting to meeting and I design my applications with this in mind.
Good, its all about second guessing the clients||designer, if a non programming analyst is involved they must be second guessed as well.
Regardz
Colin J Davies
* WARNING *
This could be addictive
The minion's version of "Catch ![Green Alien | [Alien]](https://codeproject.freetls.fastly.net/script/Forums/Images/alien.gif) "
It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
|
|
|
|
|
John M. Drescher wrote:
I have always seen that the reqirements change from meeting to meeting
Surely this is a project management issue not a coding issue.
You should not have agreed to take on a project until a contract (even a verbal agreement is a contract of sorts, but written is better) has been decided on of what you will deliver and how much you or your department will get paid. If the customer changes their mind then it is a change request that will come at a cost.
The customer will soon learn that it is more effective to get it right the first time...;P
|
|
|
|
|
J.B wrote:
The customer will soon learn that it is more effective to get it right the first time...
... or to find programmers who are willing to cope with changes in requirements.
|
|
|
|
|
Nemanja Trifunovic wrote:
or to find programmers who are willing to cope with changes in requirements.
Who will perpetually chase these requirements and go over budget and over-time. But oh yes it is an IT project so that is just normal...
|
|
|
|
|
Nemanja Trifunovic wrote:
or to find programmers who are willing to cope with changes in requirements
Good thing I am a very easy going person and fit very well into this category...
John
|
|
|
|
|
<<if the="" customer="" changes="" their="" mind="" then="" it="" is="" a="" change="" request="" that="" will="" come="" at="" cost.="">>
Ah, if only it were so easy. And I *totally* agree with you! However, you'd find yourself hard pressed for customers if you pulled that stunt too many times. Why? Because there are companies out there that will take a loss to gain business - therefore, so must your company - lest word of mouth eventually drive your customer base away toward your competiters. It sucks but that's what happens often enough.
|
|
|
|
|
Yes you are correct, but this is called managing the customer and most importantly their expectations.
It only takes one alternative competitor who cannot 'deliver' to wake them up realizing that although you lay down hard rules, you will deliver on your promises.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Sheep | [baah]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/sheep.gif)
