You don't know that. There is no way of knowing that. Use it as a mantra at project meetings sure, but realistically there is no way of knowing for sure.
Admitting that one doesn't know about the future is pretty much all there is to it. If one can do it without loosing face, one might have enough experience to call himself a professional.
A team can succeed by creating an environment that is prepared for change, on every level not only system design. This change always happens and it is exactly what separates the wheat from the chaff. Change and how well you can survive it is what makes or breaks deadlines.
Having it "all figured out" is the claim of the rookie. Experienced programmers SAVE time by avoiding design that does not survive change, ie complexities. They know they will have to SPEND it later on redesign anyway. Rookies never save time for rewriting the whole thing. A rookie will never expect to since they already "got it all figured out".
A person needs to cross a river, and so believes a bridge needs to be built.
What he should be doing is ask: "I need to cross this river, can you help me?"
Instead, he asks someone to build a bridge, a bridge of this and this dimension so his particular vehicle can pass, and a bridge with this and this feature because "it would be nice if..". He also wants a bridge that looks in this and that way, because since he is paying for the bridge he wants it to look the way he wants it to.
First he was crossing a river, he is now building a bridge. Will the bridge help him cross the river? Who knows? Maybe a bridge like he imagines can't be built, or only be built poorly.
Its the same thing with software. People want the strangest things. In fact, what they WANT is the only thing they know. They don't know what they NEED.
So you get an organisation, a business, with an office that has a problem, any problem. The problem will ALWAYS occur because some OTHER process isn't working somewhere else in the organisation. You get bad data from here, and the clerk is expected to output good data out there. In the 50's I bet they wanted more filing capability or better typewriters to solve these problems, in this day and age they want IT. They want a system!
So instead of using excel, notepad or even a piece of paper like any other sane human being would to keep track of the information, a yell echoes down the corridors: "We need software to support our business."
So some programmers are hired. They get a description of the problem, which isn't logical in the first place, and they are expected to solve it. Their tool, software, is built using a logical language. It is used to describe the data, and solve the problem by adding a few flows for that data during certain conditions.
So the programmer (or bridge builder) sits himself down. The first 10% of code/thought he outputs is usually all that should be done about the percieved problem. That is, a description of the Need.
The next 90% of coding is about the programmer trying to coerce a logical language around non-logical flows and non-optimal solutions, hammering a square button into a round whole, with GUI's, buttons and special extra functions for special extra cases, and those extra wants on top that really describe other problems.
So we will end up with a mishmash of buggy code that describes the wants of the customer. The Want to solve a problem that should have been solved with organizational changes, or changes in the work processes. But hey now everyone is happy again, software is supposed to be a bit buggy, the organisation is obviously still working non-optimally (software can't fix that), but at least the clerks now have webpages to input the bad data in as long as the servers are up.
Optimally, the programmer (yes the programmer) should look at the problem, trace it down the whole organisation, yea trace the customer Want to the REAL problem and the REAL need, proceed to make the organizational changes and be done without an IT system at all.
We all know that won't happen, but that is what should be done. Don't expect a logical function (software) that describes a non-optimal situation, to function in an optimal way.
Software doesn't work that way, thats why its hard.
Slashdot Mirror
But we *are* going to make that date.
You don't know that. There is no way of knowing that. Use it as a mantra at project meetings sure, but realistically there is no way of knowing for sure.
Admitting that one doesn't know about the future is pretty much all there is to it. If one can do it without loosing face, one might have enough experience to call himself a professional.
A team can succeed by creating an environment that is prepared for change, on every level not only system design. This change always happens and it is exactly what separates the wheat from the chaff. Change and how well you can survive it is what makes or breaks deadlines.
Having it "all figured out" is the claim of the rookie. Experienced programmers SAVE time by avoiding design that does not survive change, ie complexities. They know they will have to SPEND it later on redesign anyway. Rookies never save time for rewriting the whole thing. A rookie will never expect to since they already "got it all figured out".
Let me tell you why it is hard.
A person needs to cross a river, and so believes a bridge needs to be built.
What he should be doing is ask: "I need to cross this river, can you help me?"
Instead, he asks someone to build a bridge, a bridge of this and this dimension so his particular vehicle can pass, and a bridge with this and this feature because "it would be nice if..". He also wants a bridge that looks in this and that way, because since he is paying for the bridge he wants it to look the way he wants it to.
First he was crossing a river, he is now building a bridge. Will the bridge help him cross the river? Who knows? Maybe a bridge like he imagines can't be built, or only be built poorly.
Its the same thing with software. People want the strangest things. In fact, what they WANT is the only thing they know. They don't know what they NEED.
So you get an organisation, a business, with an office that has a problem, any problem. The problem will ALWAYS occur because some OTHER process isn't working somewhere else in the organisation. You get bad data from here, and the clerk is expected to output good data out there. In the 50's I bet they wanted more filing capability or better typewriters to solve these problems, in this day and age they want IT. They want a system!
So instead of using excel, notepad or even a piece of paper like any other sane human being would to keep track of the information, a yell echoes down the corridors: "We need software to support our business."
So some programmers are hired. They get a description of the problem, which isn't logical in the first place, and they are expected to solve it. Their tool, software, is built using a logical language. It is used to describe the data, and solve the problem by adding a few flows for that data during certain conditions.
So the programmer (or bridge builder) sits himself down. The first 10% of code/thought he outputs is usually all that should be done about the percieved problem. That is, a description of the Need.
The next 90% of coding is about the programmer trying to coerce a logical language around non-logical flows and non-optimal solutions, hammering a square button into a round whole, with GUI's, buttons and special extra functions for special extra cases, and those extra wants on top that really describe other problems.
So we will end up with a mishmash of buggy code that describes the wants of the customer. The Want to solve a problem that should have been solved with organizational changes, or changes in the work processes. But hey now everyone is happy again, software is supposed to be a bit buggy, the organisation is obviously still working non-optimally (software can't fix that), but at least the clerks now have webpages to input the bad data in as long as the servers are up.
Optimally, the programmer (yes the programmer) should look at the problem, trace it down the whole organisation, yea trace the customer Want to the REAL problem and the REAL need, proceed to make the organizational changes and be done without an IT system at all.
We all know that won't happen, but that is what should be done. Don't expect a logical function (software) that describes a non-optimal situation, to function in an optimal way.
Software doesn't work that way, thats why its hard.
The OS in the Browser in the OS in the Browser in the OS in the ..