|
he he he... read this in Other Options...
ain't it height of optimism?
-------------------
Therez No Place like ... 127.0.0.1
|
|
|
|
|
Eh, since I used to be a code project viewer, and coded for win32 I thought I would browse back over here to check out CP, and I couldn't resist.
How do I start a new project?
1. ditch proprietory O.S. that takes a given standard, hacks it up, and presents it as the new MS standard. (which of course breaks the old standard.. templates anybody?)
2. Get a OS with choices.. Can we say "Linux"?
3. Discuss and fire up Vi (See I used to think that the IDE was the answer, but now that I'm back with a good old text editor and make I re discovered how wonderful it is to code how *I* want to code).
|
|
|
|
|
Wow!!! Now, that's progress, isn't it? Just keep moving in this direction, and in a couple of years you will write assembly on Z80 processors, and in a decade or two you will discover the beauty of punched cards[^] 
|
|
|
|
|
lol. 
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
How fashionable!
Norman Fung
|
|
|
|
|
I think that the client must have the wisdom to know what he/she/it wants.
Most often, what the clients wants can not be expressed verbally or written down
in a way that can be of any use for a "coder" (the one that writes code).
Someone, such as the analyst, must interact with the original client,
rephrase things and come up with english language contexts that will,
after some iteration, be translatable to a coder.
Even if the coder and the analysts are the same person, even if the whole
thing is so small that it is never worth writing down, at some point,
a project would fail if we dont go through those motions.
The only exception to this are programmers that have a I.Q. of over 150
and happens to be the analyst AND the original client all at once!
(this case would not count, because when one is on its own, one is on its own and thats it)
What do you think ?
|
|
|
|
|
Nah.
People usually want a program written because they have a problem they need solved. If they come to you with that, great. Work with it.
What I've seen though, is that they try to solve it on their own first, and come up with what they think is the only solution. Then they go looking for a program that does exactly that.
Often they either didn't understand the problem completely in the first place, overlooked a better or more general solution, or more likely don't understand that another solution would be better given the underlying architecture.
Of course this greatly depends on what field their problems are in.
|
|
|
|
|
I tend to disagree.
The client belongs to the problem domain and the
programmer / analyst / developper belongs to the solution domain
The client may have some sort of notion about the solution domain,
but really shouldn't mess with that.
Otherwise, it's not a client, it's another "solution provider" that
hires you as a sub-contractant, maybe asking opinions and so forth.
As soon as you accept the responsibility for writing the solution,
you are the boss as far as this is concerned.
If the "client" wants to tell you how to do your job, then you cease to
have responsibility and you become a $ XX.YY / hour drone.
|
|
|
|
|
Bamaco2 wrote:
The client belongs to the problem domain and the
programmer / analyst / developper belongs to the solution domain
A lot of programmers I know are part of the problem.
Bamaco2 wrote:
The client may have some sort of notion about the solution domain,
but really shouldn't mess with that.
Otherwise, it's not a client, it's another "solution provider" that
hires you as a sub-contractant, maybe asking opinions and so forth.
Ridiculous! Do I know how to design satellites? Do I know how to run a boatyard? I need my clients to explain how they solve problems so that I can write programmers that facilitate their processes. Sure, in the process, we discover ways to improve processes as well, but that's another story.
Bamaco2 wrote:
As soon as you accept the responsibility for writing the solution,
you are the boss as far as this is concerned.
LOL! I've never seen a situation where this applies. The solution is more than just code. It's a partnership between me and the client. Being boss means having responsibility, and my client has just as much responsibility in seeing the solution developed as I do in terms of design and implementation. Each works in his/her own domain toward the solution.
Bamaco2 wrote:
If the "client" wants to tell you how to do your job, then you cease to
have responsibility and you become a $ XX.YY / hour drone.
Sure, telling me how to code isn't going to fly. But there's a lot of things my client CAN tell me that makes everyone's life a lot easier because it results in success.
You seem to be constructing a big wall between the coder and the client. This perpetuates a big problem in the industry--lack of communication. I think the differentiation you are making is pointless and in many cases dangerous to the success of the effort.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
There is definitly a fine line here and it can be the cause of much grief.
I do not agree that the client is always right. I have surrendered to a clients desires (they were used to being right all the time) Only to hate the project and the resulting code. It is red headed step son of a project that I was fortunetly able to take my name off of.
If you are not able to listen to your client and ask the right questions your project is doomed.
Likewise if your client is not willing to listen to you...walk away. Nobody will be happy and you'll probably have a hard time getting paid.
Walking away from a client or project is not always easy especially if you need the money. But the peace of mind you'll save will keep you fresh for the good clients.
Things clients do that sound my alarm:
-not pay my deposit
-tell me HOW to provide the solution
-tell me how long a project should take
-not agreeing to scheduling an adaquet testing period up front
-not agreeing to allow their employees to be part of the design process
-not allowing time for review meetings at scheduled intervals
If after the first meeting or two the clients looks like they are going to be trouble I just ask for 60% deposit, that usually starts them looking elseware 
If they want to rush the project and don't allow those who will use the system participtate, I'll just get stress and the users will get un-tested crap.
On the other hand good clients, understand the need for input from all parties towards a solution, understand that pot holes and road blocks will be hit along the way especialy as specs get changed due to new ideas or opportunities (or unforseen technical issues). Good clients want a solid system that has undergone rigorous testing. Good clients know that it costs money to do things right.
Sometimes good clients are hard to find. 
|
|
|
|
|
I'll bet most of us, who are forced to start/continue work whilst marketing makes up new features, are not proud of it.
I'd love to work in a world/company where analysis is followed by design, and development is managed.
Sigh.
Don't worry, nobody lives forever.
|
|
|
|
|
I share your pain. Now imagine if you have to be marketing as well in that you need to go and try to sell your ideas/products etc. to potential clients, get them to accept your proposals etc and still have to code them.
Sigh, I guess you're right - nobody lives forever, not in these earthen vessels anyway.
|
|
|
|
|
Bernhard Hofmann wrote:
I'll bet most of us, who are forced to start/continue work whilst marketing makes up new features, are not proud of it.
Huh. My favorite people to work with are marketing people. They're creative, are in direct contact with the customer, and are a lot of fun. By nurturing a good relationship with marketing people, they come to me and ask me first "can I say this?" and "can I do this?". A lot of times, they have good ideas on how to make a feature a little bit better. They stay on top of what the competition is doing.
I guess I just have different experiences.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
|
Most of our clients are not willing (or able) to define the requirements. We have to define the requirements for them with a few information what they really want. In most cases they need a user interface prototype to imagine what we are talking about. They resist to sign and pay for the requirements specifications and protest when they have to pay for changes during the development process.
It is really difficult to explain clients that it is important to gather the requirements as a team (client <-> developer) and that a good architecture saves money and time in later stages of a project. They believe that it is more expensive (nobody of them would build a house without a construction plan and decide to change the number of stories after the roof is covered). In my opinion the biggest mistakes, during a development cycle, are done at the very fist stage.
What are your experiences?
Stephan
|
|
|
|
|
Stephan Hoppe wrote:
In my opinion the biggest mistakes, during a development cycle, are done at the very fist stage.
This is a well known fact.
But it seem no one hase the time and money to work that way. The whole fuss about 'agile processes' and so on seems to mainly stem from the fact that there needs to be a continual flow of small success reports: Management, marketing and customers want to see something early on, just to say "We want it different."
Proably, the human mind is working that way.
Stephan Hoppe wrote:
We have to define the requirements for them with a few information what they really want.
And I am sure they are not content with what they see. But I think this is normal. In my part of the industry (bioinformatics), we often have to assist academeic customers by researching some new applications. There is way any one could have guessed beforehand what he would need most (short of saying "We need anything!"). We simply need to code, show and improve.
And while we are at it, marketing does its work and sells our first shot 
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
For one of my clients (we have worked together since 1998) I found a way which is not to bad for both of us, but to do it this way it was absolutly necessary to get a high understanding of the subject and a good relation to the client. We roughly collect and describe all requirements and group them logical. Then I start to check if they are possible to solve, how long it will take to realize them and then the client prioritize the requirements. After that we describe the first group as exactly as possible (I developed a good question and describing technique). Then I check the best way to implement the requirements, change the design, do some refactoring and implement the features. The development time wasn't much longer than the years before, but the quality is much better.
jhwurmbach wrote:
We simply need to code, show and improve.
And while we are at it, marketing does its work and sells our first shot
In my old company they sold features which nobody of us programmers knew. In my current company they sell features nobody needs. I guess the marketing people do such things only to make us mad
|
|
|
|
|
Stephan Hoppe wrote:
to get a high understanding of the subject and a good relation to the client
Yes, this is crucial to most projects that are more complicated. In our company, of 40 Softwaredevelopers, most are physicists, some chemists, one biologist (me ) and only a handful are informatics. Informatics seem too much obsessed with techniques and theories.
Customers need someone more practical to talk to.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
|
For me it's good to discuss the requirements, then research to see if any company it's makeing something similar to take ideas, then I try to do a prototype, etc, etc....
For me it's natural to do in that mode, because it's like if anybody payme to do something like a spreadsheet. You can't invent the wheel, you try to improbe it....
I only take the C option, if somebody ask me to write a new software.
I don't know if anybody agree with me.
Regards
Carlos Antollini
Do you know piFive[^] ?
|
|
|
|
|
Yap, I have to say, I feel they are the same. Depends on your job is team work or you work as your own.
Mazy
"Improvisation is the touchstone of wit." - Molière
|
|
|
|
|
But I just couldn't help laughing and thinking...
"CListCtrl"!
I simply can't get it out of my head, and sure enough, when I looked at the text answers, someone else obviously feels the same!
¡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
|
|
|
|
|
What is about the "CListCtrl"?
|
|
|
|
|
 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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
naaaa... we can't be thinking of the same types of people... I bet by marketing you really don't mean marketing per se', right? Just kinda like devs and engineers who do some marketing stuff on the side I'm sure. 
![Sheep | [baah]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/sheep.gif)