Prev: contract jobs in australia
Next: Visual Object Cobol
From: razor on 31 Dec 2009 12:22
The 'document' is sent as an attachment. Doesn't really matter to me
whether its text or HTML. Problem at store is that when they open it,
some of these people see it opened into Notepad and have never used
this program. Cue screams for training. Surely this echoes your own
experiences? As soon as you tell these staff members that instead of a
weekly fax they will now get a daily email then they will find any way
to wheedle out of agreeing to it. At least most people now have
experience of a browser rather than a text editor like notepad.

Razor
From: Richard on 31 Dec 2009 13:13
On Jan 1, 4:20 am, Howard Brazee <how...(a)brazee.net> wrote:
> On Wed, 30 Dec 2009 18:52:58 -0800 (PST), razor
>
> <irudd...(a)blueyonder.co.uk> wrote:
> >'I' don't want to send it via HTML. I was told in the past. Yes we
> >tried sending text, but the users found it too complicated (I was
> >told).
>
> Weird.    Text is "too complicated" and HTML isn't?   In e-mails?
>
> I know some e-mail programs give us options of sending e-mail in plain
> text or HTML, and others just send whatever we send.
>
> I wonder what they do with printed text.   Discard it as being too
> complicated, I suppose.
>

It seems that it is not the 'text' that is 'too complicated' but the
program(s) that the attachment opens in. The users are used to a
browser, know where 'print' is on the menu, etc. A 'text' attachment
would open in notepad, or worse, ask what was to be used and give a
list that the users have no idea about.



> --
> "In no part of the constitution is more wisdom to be found,
> than in the clause which confides the question of war or peace
> to the legislature, and not to the executive department."
>
> - James Madison

From: Richard on 31 Dec 2009 16:22
On Jan 1, 6:22 am, razor <irudd...(a)blueyonder.co.uk> wrote:
> The 'document' is sent as an attachment. Doesn't really matter to me
> whether its text or HTML. Problem at store is that when they open it,
> some of these people see it opened into Notepad and have never used
> this program. Cue screams for training. Surely this echoes your own
> experiences? As soon as you tell these staff members that instead of a
> weekly fax they will now get a daily email then they will find any way
> to wheedle out of agreeing to it. At least most people now have
> experience of a browser rather than a text editor like notepad.

If it were just a requirement to print then I would probably bypass
all the use of a GUI and implement a simple program to collect email
(sent to a specific address) and extract the attachment and print it
without any user action.

But then I have these sort of things already automated, such as
collecting emails with .xls attachments and processing these in
various ways.

From: Pete Dashwood on 31 Dec 2009 21:16
Alistair wrote:
> On Dec 31, 12:46 pm, razor <irudd...(a)blueyonder.co.uk> wrote:
>> Hi Singa
>>
>> Thanks for your suggestion.
>>
>> I would love to process all of our print files into PDF (who doesn't
>> these days) but unfortunately the client is still in 1976. Their idea
>> of 'making things better' is spending millions of � on a huge very
>> very well known all encompassing system that was supposed to replace
>> my invoicing system.
>>
>> Twice its failed spectacularly because they opt to try and change
>> their business at the same time as migrating to this new system.
>>
>> (Going slightly OT now, but maybe some will find interesting)
>>
>> I sat in a meeting with 5 'company' people and 5 'consultants'
>> discussing the new pricing rules that would be implemented. The
>> business proceeded to explain how they currently generate customer
>> prices in the existing (mine) system. All attempts to demonstrate the
>> actual process to all simply fell on deaf ears and this was not
>> because of my own personal skills, they just didn't want to listen.

Having sat in similar meetings, I sympathize. Pricing plans are always
"tricky" and I remember one U.K. company wehre they believed it could never
be effectively computerized because of all the exceptions and Sales based
spur-of-the-moment overrides.(They were wrong; it WAS computerized and
theSales people could still override it...)

Very often, especially with people whoare flogging a package, they turn off
when a processing difficulty is being outlined. The theory is that they
don't have to worry about it because the company has already bought the
package and they can "scrub round it" or put something together to dealwith
it at a later time.




>> The consultants had to listen to the business people and implement
>> what they were telling them. When the trial came around sure enough,
>> most of the prices were incorrect. I wasn't involved in the trial
>> because I didn't charge a four figure sum as my daily rate, plus
>> also, I could be besmirched for 'protecting' the existing system
>> without my knowledge. I'm a professional and would never have done
>> that.

I believe you.

I DO charge a four figure daily sum and often it is helpful, not just
because it improves the quality of my life :-), but because it actually
confers "credibility". Senior Managers tend to listen to someone who they
are paying large amounts of money for. I have even had cases where I
independently investigated something, and came up with exactly the same
conclusions and solution as their own people had already done some time
before. It was unacceptable when their own people proposed it because it was
"difficult", but they were prepared to finance and back it when I proposed
it, because they then had someone they could hang it on if it went pear
shaped. Part of my recommendation was that they should work to build better
trust with their people and start taking some responsibility for
leadership...

Remember that all you have in this life is what's in your head. You spent
years acquiring and honing it, why undervalue it? Information has value,
knowledge and expertise have value, an impeccable track record has value
(although I've never really understood that one...it seems to me that (just
like stock market investment) past performance is no guarantee of future
return...I treat every project as if it were the first, and recognise that I
REALLY don't want a failure to start the ball rolling...).

The nature of consultancy is that you will not be there for a long period of
time. (This is different from "contract programming" where the idea is to
extend your stay by whatever means are possible...:-)). It is therefore fair
and reasonable, that you should charge a higher rate. If they baulk, point
out that it is still way less than IBM or Microsoft charge for on-site
consultancy and support. (If you have either or both of these on your CV it
tends to cut some ice. You also have to be prepared to carry the can for the
project and should have professional indemnity insurance to cover this.
(Don't do like I once did, and put your house on the line if the delivery
date is not met...:-) I still have my house and enjoy living in it, but it
could have been very different if a loyal team hadn't baled me out at the
11th hour...)



>>
>> As I have a family and house to support I shall continue to roll
>> along with the status quo, although I would relish a new challenge.

Totally understand. But the two may not be mutually exclusive. You are
ideally placed to add value to what's going on, but they won't listen. Sure,
that's not your problem, you gave it your best shot, etc... but it kind of
bothers you a little to see the "status quo" continuing when that "status
quo"is getting it wrong and causing aggravation all round, right?

Here's a thought.

Formulate a document putting your concerns in writing with suggestions as to
what is needed to fix things. (A White Paper?). Circulate all the
consultants and the Business and COPY their bosses. (Don't make it too
technical... managers have limited attention spans, but it doesn't need to
be in non-joined up writing with a crayon, either. Think about what is
wrong, think about how it could be fixed and state that as simply and
directly as possible (You don't have to give them full details of a
solution; suggest an approach and let them buy the details from you). (From
your writing here I can see you don't have a problem expressing yourself.)

If anyone jumps on you for doing it (and COIs - sorry, Doc's terminology -
"Corner Office Idiots" - and Consultants are often insecure and easily
threatened by intelligent action...) simply say:" I copied all parties. My
action was up front and not deceitful. I tried to explain it in the meeting
but no-one wanted to listen. What recourse did I have? Now, at least people
are talking about it."

Setting the cat amongst the pigeons can often be beneficial for both felines
and avians...


>> Now wheres those golf clubs?
>>
>> Razor
>
> I'm glad you found the page break after to resolve your problem. It
> saves me looking up some old code and telling you it.
>
> If you really want a challenge [ ;-P ], try convincing Pete
> Dashwood that Cobol is not dead and that both India and China are
> training university graduates to code in Cobol.

It was I who pointed that out some time back, Alistair. Do try and keep up.
You should also note that they are learning COBOL as part of the "History of
Computing", and not with the idea of making a living from it.

There was an anticipated huge boom in outsourcing from the West and all of
the sub-continent started intense training programs in COBOL to meet it.
(Some people claimed there were over a million people being trained as COBOL
programmers; I have no idea whether this is true or not.) People I know in
Bangalore are telling me that this "huge boom" has peaked and is diminishing
(at least as far as COBOL is concerned; business is still healthy in other
areas...). World wide demand for COBOL is less than 3% of the total demand
for programming support. (same, usually reliable, Bangalore source). The
schools are teaching Java, C#, C++, scripting languages (PHP, Python) and
web development.

Outsourcing has been found to be flawed in a number of areas, although there
are still non-tech-savvy companies who see only the proposed bottom line and
think it is a bargain. The general levels of competence are high; the
problem is communication of requirements and understanding of Western
business processes. I know of ONE Western company who felt their outsourcing
was successful. However, their COBOL mainframe has been replaced, so they no
longer outsource COBOL.

And I never said "COBOL is dead". I said it will be by 2015 as a development
language of choice. (That is pretty much already true... so I see no reason
to modify or withdraw that statement). The procedural paradigm is definitely
dead as a model for future development, and standard COBOL implements
that.paradigm. (OO COBOL has a longer life expectancy as a useful tool for
migration of legacy, but few people will continue development in COBOL (even
OO COBOL) once they have migrated to more modern platforms.)

Are you saying that COBOL is as alive and well as it was 30 years ago?
Looked at Jobserve (U.K.) lately?

By all means, take issue with what I say, Alistair. I don't even mind being
misquoted if it is obvious you are having a laugh.

But if you intend to have a serious discussion, then please don't ascribe to
me positions I have never held and do not currently hold.

That's just kind of pointless.

Pete.

--
"I used to write COBOL...now I can do anything."


From: Tim Boyer on 1 Jan 2010 17:12
On Thu, 31 Dec 2009 04:46:57 -0800 (PST), razor
<iruddock(a)blueyonder.co.uk> wrote:

>Hi Singa
>
>Thanks for your suggestion.
>
>I would love to process all of our print files into PDF (who doesn't
>these days) but unfortunately the client is still in 1976. Their idea
>of 'making things better' is spending millions of � on a huge very
>very well known all encompassing system that was supposed to replace
>my invoicing system.
>

Dang, he beat me to it. I just print 'em out as text files, and then
call enscript/ps2pdf to get them to pdf, and send them out.

How about txt2html? http://txt2html.sourceforge.net/



-- tim --
tim(a)denmantire.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: contract jobs in australia
Next: Visual Object Cobol