|
|
Coding is no more 'FUN' when requirement change 'FREQUENTLY'
(**I think, Requirements will not freeze until last user dead  )
|
|
|
|
|
Of course it is! They happen - we all know that! So design for changes, prepare for changes, and see them as a challenge. They are there to make the final product better to use - so embrace them, expect them, and make your code flexible enough to absorb them!
And if all else fails, blame them for your late delivery / bugs / total failure of the project - and demand a pay raise! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
You would have serious trouble on our team, requirements tend to be what we can extract from the users when they are not too busy to talk to us.
When we then deliver the prototype we actually get some idea of what they really want.
|
|
|
|
|
Make sure that you get paid every time they change it, and that there is formal processes that needs to be followed in case of a change. We've fallen in the trap of customers talking directly to the developers about changing a requirement just quickly. This change was many times undocumented and nobody knew about it. It was done for free. Sometimes even a big shot at your company (e.g. CEO) want you to change something quickly.... these changes are nono's. If something needs to change, your project manager should come to you and ask you to provide him with the amount of hours it would take to change this thing. He should then add some time to that for in case it can't be done within that timeframe and multiply that with whatever the rate per hour is. Then he should give that to the marketing people who have their own agenda's and finally the price of the change is sent to the customer.
At the end of the day the customer should, before changing the requirement know how much it is going to cost to change the requirement.
Lots of times they will see than keeping something the way it is, is sufficient. That it is not worth the money you are charging for changing the requirement. Or they keep it the way it is until they have money to change it, thereby delaying the process.
|
|
|
|
|
At work I'm mostly doing SSIS, which is dreary, but I try to find something to code.
Other than that, Code Project provides ample opportunity to exercise my little grey cells so I can continue to enjoy it.
Thanks, Chris!
|
|
|
|
|
Stop bragging. 
Here is what you mean:
At work I'm mostly trying to get SSIS working, but I try to find something to code.
Other than that, Code Project Q & A provides ample opportunity to pull my little grey hair so I can continue to swear even when I am not working with SSIS.
PS: Does quote selected text button work for you? For me it posted the reply.
|
|
|
|
|
Hmmm, yes, we are in similar boats. Except, while SSIS might be considered programming, it is definitely not coding. 
I have to dig around to come up with things to code before my boss notices.
|
|
|
|
|
How would your customer react if you wrote in email that "I am running for ISIS jobs" instead of "I am running SSIS jobs."?
|
|
|
|
|
I get SSIS to work as well as it can, but it doesn't scale to meet our needs, so I'd much rather do it the right way.
lw@zi wrote: PS: Does quote selected text button work for you? For me it posted the reply.
Seems OK to me.
|
|
|
|
|
I once did an SSIS ETL package.
Step 1 - read in source file
Step 2 - call script in c# that opens a connection to the database and bulk copies the data into a staging table
Step 2a - script calls stored procedure to do the transforms.
This style scales nicely 
|
|
|
|
|
I guess subject says it all.
I do not like everything I need to do at work but if I break down my responsibilities to programming and non-programming ones, I sure love former.
|
|
|
|
|
The only time I have fun at work is when I'm programming. The rest is brutal!
modified 28-Nov-16 0:29am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
