Recommending a technology

[Michael Gautier]

This can be considered a complex, multiple form, workflow, offline/online
application that has to be cross platform.

I read your post and especially liked the part when you said, "They have no
real idea what is involved
in attempting such a distributed project, they have not talked .....". I
warned them three days ago that they may be biting off more than we can chew
at this time. I told them about the development risk of research eating up
the development schedule. I even recommended an alternate strategy where
they do an HTML based site now and do the more complex, offline/online,
cross platform client application later. Each of these points gave them
pause for a few seconds. In the end, however, they will learn at my expense,
because will be a technical failure for me, but a learning opportunity for
them. He finally admitted that if we were a few months late, that wouldn't
bother him. I know for a fact that his boss doesn't feel the same way, but
since I don't to the back stabbing thing, oh well . . . .

Thing is, I worked at various technology companies before working here. This
is an IT company inside of a larger company and this would be their first
offline/synchronization application attempt. I was accustomed to meeting
deadlines, having practical, effective, executable technical strategies and
processes. Fortunately or Unfortunately, this is my first exposure to a
Mainframe oriented organization with pc application spinoffs here and there.
Things certainly are different. There is more beauracracy, conservatism,
status quo and pc application projects are managed by former (top) mainframe
programmers trying to make technical decisions on technologies they have no
hands on experience with. Has anyone had to deal with this? How do I better
approach this situation, because the only approach I have had so far has
been reactionary? For example, they think linearly on everything, and even
though I explain threads, they still think linearly so it results in the
divergent technical recommendations and the traditional approaches win most
of the time. Or could it be because I am 25 with knowledge of recent
technology practices and they are 40 and have vast experience in
procedural/database stuff on the mainframe?


"Alan" <amassey@multiplan.com> wrote in message
news:3d7cda8c$1@10.1.10.29...
>
> If this is a complicated data entry GUI, then this applies. If it's ten
lines
> and two buttons, what's the big deal?
>
> I ran into this with a product I implemented for a large EDI translator
vendor.
> Their solution was ActiveX controls which limited both the server and
client
> platforms to Microsoft. The ability to quickly modify the code for
customer
> specific data entry screens made the product work somewhat along with the
> ability to enter data off-line, but it eventually failed due to the
complexity
> of the application issues at that time (about three years ago ActiveX
controls
> over the web, YECH!).
>
> Their second attempt at a solution was an XML based application that
utilized
> JavaScript and XSLT transforms. This provided the "thin client", but
required
> that the client stay connected to a web server. We all know the problems
> that surround this, so I won't go into it here.
>
> I have also had experience with Java solutions for the very task before
you.
> Those solutions suffered from the same issues that have plagued Java from
> the start. Many of these issues have been addressed in the past few
years,
> however. Your ramp up time will more than blow out the three months of
development
> time you have. Without a debugger and working from a VB background you
will
> be lost and the code will be filled with logic errors like you wouldn't
believe.
>
> My point is this: Many compaines (big companies) have tried to do what
you
> have been asked to do and failed. These companies had many years and big
> budgets. You have neither the time nor I'll venture to guess the money.
>
>
> You stated that this was a mainframe only shop until recently when it went
> client server. I see this project being the same mistake that many other
> mainframe shops have made before them. They have no real idea what is
involved
> in attempting such a distributed project, they have not talked to anyone
> who has attempted such a project and you get the "Pointy Haired Boss" line
> "Anything I don't understand must therefore be trivial." moving into play.
>
> Platform independence is a pie in the sky desire. Java, for all it's
greatness,
> does not delive true platform independance because the VM's out there are
> not all the same. I come from many years of experience with Java across
> platforms when I make this statement.
>
> Save yourself and your company quite a bit of frustration. Wait until you
> have a better handle on the only technologies that are going to come close
> to being what the project requires in my opinion, Flash and Adobe. There
> are to many pitfalls with the other choices.

[Michael Gautier]

Could you elaborate a bit on the planning for cross platform Java as well as
what some of the tricky issues could be?


"MarkN" <m@n.com> wrote in message news:3d7dcb2c$1@10.1.10.29...
>
> <Q>
> Platform independence is a pie in the sky desire. Java, for all it's
greatness,
> does not delive true platform independance because the VM's out there are
> not all the same. I come from many years of experience with Java across
> platforms when I make this statement.
> </Q>
>
> Many others have and are successfully accomplishing this goal. It is not
> alway 100% (i.e. CICS on PCs?). Java platform independence is over-hyped
> but it is not pie in the sky. You do have to plan for it. And it is
better
> than nothing at all. While Flash is cool and creates cool interfaces, it
> brings up alot of other issues (Single vendor, etc.).

[MarkN]

<Q>
For example, they think linearly on everything, and even
though I explain threads, they still think linearly so it results in the
divergent technical recommendations and the traditional approaches win most
of the time. Or could it be because I am 25 with knowledge of recent
technology practices and they are 40 and have vast experience in
procedural/database stuff on the mainframe?
</Q>

I run into this too. Funny thing is, most programmers think this way. Even
those using OO languages like Java and C#. Most VBers and ASPers have trouble
getting past procedural/database thinking. They just do it with newer tools.
They may throw in XMl but now it is not database data it is XML data.

It seems the project you are on is not a simple little whip it out thing.
There are major current and future issues to think about. Sounds like
fun (except for the politics stuff). You need someone with a good mix of
both platforms but with good architectual skills.

[MarkN]

Mostly it is being aware of using non-cross platform 3 party tools. Also
things like the file system - don't use things like "C:\" and rootName +
"\" + filename. Anything that is not cross platform make sure you talk via
interface - which of course is what you should be doing anyway. For most
things you do, you should have few if any issues. If you are doing graphics
or multimedia you may have more issues.


No matter what, you want to test on your target platforms. Think VB programs
always work on all windows machines?

"Michael Gautier" <gautier_michael@hotmail.com> wrote:
>Could you elaborate a bit on the planning for cross platform Java as well
as
>what some of the tricky issues could be?
>
>
>"MarkN" <m@n.com> wrote in message news:3d7dcb2c$1@10.1.10.29...
>>
>> <Q>
>> Platform independence is a pie in the sky desire. Java, for all it's
>greatness,
>> does not delive true platform independance because the VM's out there
are
>> not all the same. I come from many years of experience with Java across
>> platforms when I make this statement.
>> </Q>
>>
>> Many others have and are successfully accomplishing this goal. It is
not
>> alway 100% (i.e. CICS on PCs?). Java platform independence is over-hyped
>> but it is not pie in the sky. You do have to plan for it. And it is
>better
>> than nothing at all. While Flash is cool and creates cool interfaces,
it
>> brings up alot of other issues (Single vendor, etc.).
>
>

[Guy Smith]

>There is more beauracracy, conservatism,
>status quo and pc application projects are managed by former (top) >mainframe
programmers trying to make technical decisions on technologies >they have
no hands on experience with. Has anyone had to deal with this? > How do I
better approach this situation, because the only approach I >have had so
far has been reactionary? For example, they think linearly on > everything,
and even though I explain threads, they still think linearly > so it results
in the divergent technical recommendations and the >traditional approaches
win most of the time.

I've dealt with issues such as these before. Your best approach to this
situation is to "run like ****". Honestly.

I spent a few years trying to "update" the development practices of a software
company. Same problems. People at the top thought they knew it all and
were lost in the past. I spent time pushing for change only to realize the
company didn't even think there was a problem. Change like this is a HUGE
undertaking.

You are going to need to educate the people at the top. But, because they
haven't taken the time to educate themselves (thread programming has been
around for YEARS... can you spell U-N-I-X and C?), they are not bloody likely
to start because some young gun thinks they should. They probably don't even
recognize themselves as being a problem. Want to rock the boat by implying
to senior managers they are outdated or aren't doing their job properly?
If you start now, it will probably take 6 months to a year to convince them
that there is a problem, and much longer to fix it. Hopefully you have a
few years to invest in this company and are prepared for failure.

Another thing to concider is there may not be a problem. If the company
is making money as-is, even if they are ***-backwards, they may be happy
with how things are. Or perhaps they looked at updating and realized it
just isn't cost effective at this point.

If you can, grab an open minded senior manager, sit down and express what
you've experienced. See what the manager thinks of the matter. You'll probably
get some perspectives you have not concidered and perhaps some good advice.

>Or could it be because I am 25 with knowledge of recent technology >practices
and they are 40 and have vast experience in procedural/database >stuff on
the mainframe?

I wouldn't say this is an age issue. It is more of a "company culture" issue.
The company culture obviously doesn't embrace teaching their staff new technology
and evolving with the times. Company culture is very hard to change because
it is the foundation of the company.

Imagine a law firm that stopped learning new laws 10 years ago! Funny how
this seems to be the "norm" in some software companies.

Guy

[Markn]

>I've dealt with issues such as these before. Your best approach to this
>situation is to "run like ****". Honestly.

Sounds like pretty much every place I've worked at or heard of. Running
won't do. Doesn't matter if it is a mainframe shop or a VB/ASP shop. They
are no better than each other. Linear is no better than GUI first.