|
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.
|
|
|
|
|
True, enough! 
Let's hope my company's management learns this.
|
|
|
|
|
I voted for #2, but prioritizing a list of requirements is hardly sufficient groundwork for a design, if I want to get more than a few hours into design before needing to re-assess what the hell we're trying to do. A "list" is just my first stage of requirements gathering. Then come wire diagrams and use cases (depending on the project), and iterations on versions of those simple docs, involving meetings and emails and cubicle visits. I think this is what smart people call requirements analysis, I'm not sure. But I do know it is amazing when you write out the details of "obvious" requirements (like how the login page should work) and suddenly big issues pop up -- usually from those people who originally thought the whole project was simple and obvious. I like it when this happens, especially if I haven't even opened Visual Studio yet.
Brad Williams
|
|
|
|
|
it should have been "Get requirements, design, code, repeat as necessary"
Of course, the processes has to be re-iterative. There's no way you can forsee everything. Some issues only occur when you start implementing, although there shouldn't be too many big changes
|
|
|
|
|
... it is necessary to start a new project. Sometimes problems can be solved without starting a new project and battles can be won without actually fighting the enemy. 
|
|
|
|
|
...you can tell the customers to look for another company. Thats the best way to get rid of projects... 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
