Adobe goes into back-peddling panic mode

On 6/7/2013 1:27 PM, Tony Cooper wrote:
On Fri, 07 Jun 2013 11:06:22 -0400, Scott Schuckert
wrote:

In article , nospam
wrote:

In article
,
RichA wrote:

Microsoft is also jumping on this bandwagon with "Microsoft-branded
Services" in-place of owned programs.

lots of companies are and expect more in the future.

You'll be happily using your Adobe PS and up will pop an ad.

no.

This is nothing new, just more signs of the MBAs taking over from the
programmers and marketing people.

What is the difference between "marketing people" and "MBAs"? An MBA
is simply an advanced degree. Many "marketing people" have MBAs. The
MBA stands for Masters in Business Administration. Marketing is part
of business administration.

True


MBAs, and other management people who may not have this advanced
degree, *should* take over the function of "programmers" in business
decisions if those people are involved on the business side of the
organization. A programmer is a person who designs a computer program
to facilitate what other people decide needs to be accomplished.
Programmers do not originate the idea; they work to assigned tasks.


A programmer only writes the code to accomplish the task. However, in
many cases management uses a business analyst to translate business
requirements into geek. One of the biggest problems with programmers is
getting them to stop, when a practical result has been reached. See my
reply to nospam for the difference between a programmer and a business
analyst.



They may say "We can add this feature", but - in that role - they are
just expanding the task given to them.

A programmer need not - and usually doesn't - have any idea of the
function or objectives of the business. Tell a programmer that
something is needed to keep track of inventory, and he'll do it. He
doesn't need to know what the inventory does, who it is sold to, or
anything about the nature of the business other than the specifics of
what he's assigned to keep track of.

Selling an indefinite license gives
you big spikes in the revenue stream, and accountants HATE that. They
want a nice, smooth flow of money, like the electric utility.

Accountants merely keep track of the income/outgo. The management
people who are concerned with revenue flow are the ones who feel that
the numbers affect the share prices.

You have described a bookkeeper, not an accountant.
Good accountants also: give management financial advice, including, but
not limited to, assistance in obtaining financing, cost analysis, cash
flow analysis, leasing v pruchase decisions, tax effects of financial
decisions, etc.


Twenty years ago, my sales manager (at ComputerLand, of all places) was
trying to get me away from the big deals: "I don't want a
million-dollar PO; I want a customer who'll spend $100,000 EVERY MONTH.

Do the math. Your $100k a month customer spends more in a year than
your million-dollar one-time buyer, and he is likely to continue to
spend at that rate. Your sales manager was looking at the big
picture.





I doubt if your sales manager discouraged you from taking a
million-dollar order, but he was right in encouraging you to look for
customers who would buy and continue to buy.



--
PeterN

On 6/7/2013 2:49 PM, nospam wrote:
In article , PeterN
wrote:

Here's how it works, at least in custom designed software.
(simplified so you can understand it.)
Management makes a decision on what its needs are.
The business analyst creates a programming flow on how, if feasible to
implement, may even have to convince management to revise its requirements.
Programmers write the code for the implementation;
Business analyst tests the code,

there are companies who write to spec, but that's the minority of
programming.

typically, *both* programmers and management come up with ideas.
management generally wants the impossible and programmers bring it back
to reality. in no case does a business analyst, who hasn't a clue about
programming, come up with anything related to programming or
feasibility because it's not part of their skill set.

furthermore, business analysts do not test anything. that's sqa and
beta testers, who then submit bug reports back to the programmers who
then fix the bugs and release a new build to be tested.

I specifically referred to in house IT departments. The analysts tests
the programs to ensure it meets the business requirements. Schedules are
very tight, and 90-100 hour weeks are not uncommon for the two months
before the new program goes live. BTW are you aware that crash recovery
in some businesses is under five seconds? Access security for some
institutions is tighter than the US Govt. They do not use beta testers.
everything is internal.


other times, programmers themselves come up with the ideas and pitch
them to the higher-ups. for instance, google employees spend a portion
of their time working on any pet project they want. some of those pet
projects become real products, including gmail and google+ (originally
wave). those weren't ideas that management came up with. they were
ideas that programmers came up with.

BTW business analysts paid a lot more than programmers.

no they definitely aren't. programmers can easily make quite a bit more
than any analyst and many times they can write their own ticket.


For clarity I am calling using the term programmer as equal to code writer.
Are you speaking with knowledge?
I have actual knowledge of pay scales, based on what people actually do.




Strange, I know well paid business analysts who can't write two lines of
code.

--
PeterN

On 6/7/2013 5:08 PM, Tony Cooper wrote:
On Fri, 07 Jun 2013 16:32:30 -0400, PeterN
wrote:

On 6/7/2013 1:27 PM, Tony Cooper wrote:
On Fri, 07 Jun 2013 11:06:22 -0400, Scott Schuckert
wrote:

In article , nospam
wrote:

In article
,
RichA wrote:

Microsoft is also jumping on this bandwagon with "Microsoft-branded
Services" in-place of owned programs.

lots of companies are and expect more in the future.

You'll be happily using your Adobe PS and up will pop an ad.

no.

This is nothing new, just more signs of the MBAs taking over from the
programmers and marketing people.

What is the difference between "marketing people" and "MBAs"? An MBA
is simply an advanced degree. Many "marketing people" have MBAs. The
MBA stands for Masters in Business Administration. Marketing is part
of business administration.

True


MBAs, and other management people who may not have this advanced
degree, *should* take over the function of "programmers" in business
decisions if those people are involved on the business side of the
organization. A programmer is a person who designs a computer program
to facilitate what other people decide needs to be accomplished.
Programmers do not originate the idea; they work to assigned tasks.


A programmer only writes the code to accomplish the task. However, in
many cases management uses a business analyst to translate business
requirements into geek. One of the biggest problems with programmers is
getting them to stop, when a practical result has been reached. See my
reply to nospam for the difference between a programmer and a business
analyst.



They may say "We can add this feature", but - in that role - they are
just expanding the task given to them.

A programmer need not - and usually doesn't - have any idea of the
function or objectives of the business. Tell a programmer that
something is needed to keep track of inventory, and he'll do it. He
doesn't need to know what the inventory does, who it is sold to, or
anything about the nature of the business other than the specifics of
what he's assigned to keep track of.

Selling an indefinite license gives
you big spikes in the revenue stream, and accountants HATE that. They
want a nice, smooth flow of money, like the electric utility.

Accountants merely keep track of the income/outgo. The management
people who are concerned with revenue flow are the ones who feel that
the numbers affect the share prices.

You have described a bookkeeper, not an accountant.
Good accountants also: give management financial advice, including, but
not limited to, assistance in obtaining financing, cost analysis, cash
flow analysis, leasing v pruchase decisions, tax effects of financial
decisions, etc.

I shouldn't slight the role of an accountant. All of what you said
above is true, but the accountant shouldn't let the share price affect
his decisions on the above points.

Especially if the accountant is also an independent auditor, who
prepares financial statements.



If you want to look at the OP's rather naif comment as a cash flow
problem, then the accountant might prefer regular feedings instead of
binging. I doubt if the OP is that aware, though.




--
PeterN

In article , Tony Cooper
wrote:

Job titles,
like salary, are important to people.

maybe titles once did, but not anymore. what matters more is what the
job actually is and how it's changing the world. now, people get
creative with job titles rather than use old stodgy boring ones.

http://www.canada.com/When+title+just+title/6314032/story.html
"We're definitely seeing it at all levels, across a wide range of
industries," he says. "Tech companies have been showing innovation in
their business titles for a while now, but we're also seeing it a lot
in jobs ranging from cleaning services to transportation to plumbing.
Titles like 'executive' or 'manager' don't have as much meaning in
some people's minds nowadays."

Do you realize that you have just proved my point?

except, i didn't.

"Showing innovation" is just another term for "making employees feel
better by giving them more important titles". If the title is still
"programmer", the employee and the employer both feel the title
reflects the job...which is just programming.

the point is that titles don't mean much. a title doesn't define a job,
creative or otherwise. people don't accept a job just because they get
to put 'code ninja' or something cute on their business card, they take
the job because it's interesting work.

As immortalized in the movie The Social Network, Facebook founder
Mark Zuckerberg once ordered business cards reading: "I'm CEO,
bitch." Job titles at branding consultancy I-Am Associates include
Success Catalyst, Daydream Believer and Stone TurnerOverer.

Your comment that titles mean
nothing exposes you're complete lack of understanding human nature and
the business world. A company can often get away with denying a raise
in salary just by giving the person a more important sounding title.

not if they want to keep their talent, they don't.

All "talent" is not equal.

no kidding. that's why some people get paid more than others.

"Can often..." recognizes this and says
that if marginal talent can be kept with a title promotion, then the
talent stays. If the marginal talent can't be retained with this type
of puffery, then the company says "So long" and plugs in another
person.

more likely the other way around. the person says goodbye and takes a
better offer at a competitor, where they're treated with respect.

people aren't as disposable as you think.

In article , PeterN
wrote:

Here's how it works, at least in custom designed software.
(simplified so you can understand it.)
Management makes a decision on what its needs are.
The business analyst creates a programming flow on how, if feasible to
implement, may even have to convince management to revise its requirements.
Programmers write the code for the implementation;
Business analyst tests the code,

there are companies who write to spec, but that's the minority of
programming.

typically, *both* programmers and management come up with ideas.
management generally wants the impossible and programmers bring it back
to reality. in no case does a business analyst, who hasn't a clue about
programming, come up with anything related to programming or
feasibility because it's not part of their skill set.

furthermore, business analysts do not test anything. that's sqa and
beta testers, who then submit bug reports back to the programmers who
then fix the bugs and release a new build to be tested.

I specifically referred to in house IT departments.

no, you said custom designed software, not it departments.

it's still quoted above.

plus, it departments aren't the only type of programming out there.

The analysts tests
the programs to ensure it meets the business requirements.

in other words, beta testers.

the programmers test the software before anyone else ever sees it. they
don't release something that doesn't work. that wastes everyone's time.

Schedules are
very tight, and 90-100 hour weeks are not uncommon for the two months
before the new program goes live.

nothing unusual there.

BTW are you aware that crash recovery
in some businesses is under five seconds?

that's long.

are you aware that it can unnoticeable, if designed properly?

Access security for some
institutions is tighter than the US Govt. They do not use beta testers.
everything is internal.

that just means they don't use *external* beta testers. it still has to
be tested. anyone who releases untested code is going to have problems.

other times, programmers themselves come up with the ideas and pitch
them to the higher-ups. for instance, google employees spend a portion
of their time working on any pet project they want. some of those pet
projects become real products, including gmail and google+ (originally
wave). those weren't ideas that management came up with. they were
ideas that programmers came up with.

BTW business analysts paid a lot more than programmers.

no they definitely aren't. programmers can easily make quite a bit more
than any analyst and many times they can write their own ticket.

For clarity I am calling using the term programmer as equal to code writer.
Are you speaking with knowledge?
I have actual knowledge of pay scales, based on what people actually do.

so do i.

i'm also not comparing an entry level programmer, what you call a 'code
writer', with a top level business analyst. that's a meaningless and
disingenuous comparison.

iphone/android programmers who work for a company can easily make
$100k/yr to start without even trying all that hard, and often quite a
bit more if they're any good.

if they write a successful app on their own, they can make a *lot* more
money, sometimes as much as $1m/yr or more.

Strange, I know well paid business analysts who can't write two lines of
code.

nothing strange about it.

On 6/7/2013 6:48 PM, nospam wrote:
In article , PeterN
wrote:

Here's how it works, at least in custom designed software.
(simplified so you can understand it.)
Management makes a decision on what its needs are.
The business analyst creates a programming flow on how, if feasible to
implement, may even have to convince management to revise its requirements.
Programmers write the code for the implementation;
Business analyst tests the code,

there are companies who write to spec, but that's the minority of
programming.

typically, *both* programmers and management come up with ideas.
management generally wants the impossible and programmers bring it back
to reality. in no case does a business analyst, who hasn't a clue about
programming, come up with anything related to programming or
feasibility because it's not part of their skill set.

furthermore, business analysts do not test anything. that's sqa and
beta testers, who then submit bug reports back to the programmers who
then fix the bugs and release a new build to be tested.

I specifically referred to in house IT departments.

no, you said custom designed software, not it departments.


Whether custom designed software is outsourced or developed internally,
the process flow is the same. Your comment about the analyst not
testing anything is incorrect, in the context of my comment.

it's still quoted above.

plus, it departments aren't the only type of programming out there.

Never said they were.

The analysts tests
the programs to ensure it meets the business requirements.

in other words, beta testers.

Earlier you said analysts do not test, now you agree they do. We are
making progress.


the programmers test the software before anyone else ever sees it. they
don't release something that doesn't work. that wastes everyone's time.


A programmer/code writer, will only test their snippets. Not how the
whole program functions with all the snippets in place.

Schedules are
very tight, and 90-100 hour weeks are not uncommon for the two months
before the new program goes live.

nothing unusual there.

BTW are you aware that crash recovery
in some businesses is under five seconds?

that's long.

are you aware that it can unnoticeable, if designed properly?

The necessity for rapid crash recovery time depends on the function.


Access security for some
institutions is tighter than the US Govt. They do not use beta testers.
everything is internal.

that just means they don't use *external* beta testers. it still has to
be tested. anyone who releases untested code is going to have problems.

other times, programmers themselves come up with the ideas and pitch
them to the higher-ups. for instance, google employees spend a portion
of their time working on any pet project they want. some of those pet
projects become real products, including gmail and google+ (originally
wave). those weren't ideas that management came up with. they were
ideas that programmers came up with.

BTW business analysts paid a lot more than programmers.

no they definitely aren't. programmers can easily make quite a bit more
than any analyst and many times they can write their own ticket.

For clarity I am calling using the term programmer as equal to code writer.
Are you speaking with knowledge?
I have actual knowledge of pay scales, based on what people actually do.

so do i.

i'm also not comparing an entry level programmer, what you call a 'code
writer', with a top level business analyst. that's a meaningless and
disingenuous comparison.

iphone/android programmers who work for a company can easily make
$100k/yr to start without even trying all that hard, and often quite a
bit more if they're any good.

if they write a successful app on their own, they can make a *lot* more
money, sometimes as much as $1m/yr or more.

Strange, I know well paid business analysts who can't write two lines of
code.

nothing strange about it.



--
PeterN

In article , PeterN
wrote:

Here's how it works, at least in custom designed software.
(simplified so you can understand it.)
Management makes a decision on what its needs are.
The business analyst creates a programming flow on how, if feasible to
implement, may even have to convince management to revise its
requirements.
Programmers write the code for the implementation;
Business analyst tests the code,

there are companies who write to spec, but that's the minority of
programming.

typically, *both* programmers and management come up with ideas.
management generally wants the impossible and programmers bring it back
to reality. in no case does a business analyst, who hasn't a clue about
programming, come up with anything related to programming or
feasibility because it's not part of their skill set.

furthermore, business analysts do not test anything. that's sqa and
beta testers, who then submit bug reports back to the programmers who
then fix the bugs and release a new build to be tested.

I specifically referred to in house IT departments.

no, you said custom designed software, not it departments.

Whether custom designed software is outsourced or developed internally,
the process flow is the same. Your comment about the analyst not
testing anything is incorrect, in the context of my comment.

changing it yet again? first it's custom designed, then it's it
departments and now it's outsourced versus internal.

it's still quoted above.

plus, it departments aren't the only type of programming out there.

Never said they were.

it's not representative of the industry.

The analysts tests
the programs to ensure it meets the business requirements.

in other words, beta testers.

Earlier you said analysts do not test, now you agree they do. We are
making progress.

anyone can test something. it doesn't have to be an analyst. anyone can
see if something works and meets the specs.

the programmers test the software before anyone else ever sees it. they
don't release something that doesn't work. that wastes everyone's time.

A programmer/code writer, will only test their snippets. Not how the
whole program functions with all the snippets in place.

not necessarily. they might (and often do) test more than just their
own snippet.

you are making very big generalizations.

Schedules are
very tight, and 90-100 hour weeks are not uncommon for the two months
before the new program goes live.

nothing unusual there.

BTW are you aware that crash recovery
in some businesses is under five seconds?

that's long.

are you aware that it can unnoticeable, if designed properly?

The necessity for rapid crash recovery time depends on the function.

backpedalling.

why would someone want slower recovery?

and most of the time that doesn't matter. consumer pcs and apps don't
have any crash recovery at all.

On 6/8/2013 7:58 PM, nospam wrote:
In article , PeterN
wrote:

Here's how it works, at least in custom designed software.
(simplified so you can understand it.)
Management makes a decision on what its needs are.
The business analyst creates a programming flow on how, if feasible to
implement, may even have to convince management to revise its
requirements.
Programmers write the code for the implementation;
Business analyst tests the code,

there are companies who write to spec, but that's the minority of
programming.

typically, *both* programmers and management come up with ideas.
management generally wants the impossible and programmers bring it back
to reality. in no case does a business analyst, who hasn't a clue about
programming, come up with anything related to programming or
feasibility because it's not part of their skill set.

furthermore, business analysts do not test anything. that's sqa and
beta testers, who then submit bug reports back to the programmers who
then fix the bugs and release a new build to be tested.

I specifically referred to in house IT departments.

no, you said custom designed software, not it departments.

Whether custom designed software is outsourced or developed internally,
the process flow is the same. Your comment about the analyst not
testing anything is incorrect, in the context of my comment.

changing it yet again? first it's custom designed, then it's it
departments and now it's outsourced versus internal.

It has ALWAYS been custom designed software. You are putting in
irrelevant parameters.



it's still quoted above.

plus, it departments aren't the only type of programming out there.

Never said they were.

it's not representative of the industry.


What industry. Another airplane survey?
The analysts tests
the programs to ensure it meets the business requirements.

in other words, beta testers.

Earlier you said analysts do not test, now you agree they do. We are
making progress.

anyone can test something. it doesn't have to be an analyst. anyone can
see if something works and meets the specs.


Congratulations, you have now made the most ignorant statement I have
seen from you.

If a tester has no understanding of why the specs were promulgated,
there is no way he can effectively test. Testing includes workability,
and legal compliance.

I now understand why you have no clue as to what a sophisticated
business analyst does.

the programmers test the software before anyone else ever sees it. they
don't release something that doesn't work. that wastes everyone's time.

A programmer/code writer, will only test their snippets. Not how the
whole program functions with all the snippets in place.

not necessarily. they might (and often do) test more than just their
own snippet.

Not in custom designed software. They simply do not know what the other
snippets are supposed to do.


you are making very big generalizations.

Schedules are
very tight, and 90-100 hour weeks are not uncommon for the two months
before the new program goes live.

nothing unusual there.

BTW are you aware that crash recovery
in some businesses is under five seconds?

that's long.

are you aware that it can unnoticeable, if designed properly?

The necessity for rapid crash recovery time depends on the function.

backpedalling.

Pointing out reality.


why would someone want slower recovery?

and most of the time that doesn't matter. consumer pcs and apps don't
have any crash recovery at all.

Irrelevant.

When I mentioned custom programming, a business analyst, and
programmer/coder, you should have realized that consumer PCs have
nothing to do with the subject.

Although irrelevant to my point, I can think of several comsumer apps
that have a form of crash recovery. It's called automatic backup.
Let's try some common ones.
Excel,
Photoshop
WordPerfect;
Word. etc
Internet Explorer;

--
PeterN

In article , PeterN
wrote:

Here's how it works, at least in custom designed software.
(simplified so you can understand it.)
Management makes a decision on what its needs are.
The business analyst creates a programming flow on how, if feasible to
implement, may even have to convince management to revise its
requirements.
Programmers write the code for the implementation;
Business analyst tests the code,

there are companies who write to spec, but that's the minority of
programming.

typically, *both* programmers and management come up with ideas.
management generally wants the impossible and programmers bring it back
to reality. in no case does a business analyst, who hasn't a clue about
programming, come up with anything related to programming or
feasibility because it's not part of their skill set.

furthermore, business analysts do not test anything. that's sqa and
beta testers, who then submit bug reports back to the programmers who
then fix the bugs and release a new build to be tested.

I specifically referred to in house IT departments.

no, you said custom designed software, not it departments.

Whether custom designed software is outsourced or developed internally,
the process flow is the same. Your comment about the analyst not
testing anything is incorrect, in the context of my comment.

changing it yet again? first it's custom designed, then it's it
departments and now it's outsourced versus internal.

It has ALWAYS been custom designed software. You are putting in
irrelevant parameters.

no it hasn't. custom designed software is not necessarily it
departments, and whether it's outsourced/internal is an entirely
separate issue.

in fact, some custom designed software can be *both* outsourced and
internal. been there done that.

it's still quoted above.

plus, it departments aren't the only type of programming out there.

Never said they were.

it's not representative of the industry.

What industry. Another airplane survey?

the software industry. do try to keep up.

The analysts tests
the programs to ensure it meets the business requirements.

in other words, beta testers.

Earlier you said analysts do not test, now you agree they do. We are
making progress.

anyone can test something. it doesn't have to be an analyst. anyone can
see if something works and meets the specs.

Congratulations, you have now made the most ignorant statement I have
seen from you.

nothing ignorant about it. have you ever worked with testers? i have.

If a tester has no understanding of why the specs were promulgated,
there is no way he can effectively test. Testing includes workability,
and legal compliance.

a tester does not need to know why, only that the product does what its
supposed to do without crashing, data loss, etc.

also, many testers have useful comments on whether the design is good
or not, some of which end up being implemented.

I now understand why you have no clue as to what a sophisticated
business analyst does.

business analysts are anything but sophisticated.

what's clear is you know very little about software development. all
you know is your limited experience with it departments which is not
representative of the software industry, as i said.

the programmers test the software before anyone else ever sees it. they
don't release something that doesn't work. that wastes everyone's time.

A programmer/code writer, will only test their snippets. Not how the
whole program functions with all the snippets in place.

not necessarily. they might (and often do) test more than just their
own snippet.

Not in custom designed software. They simply do not know what the other
snippets are supposed to do.

yes in custom designed software. i've done numerous such projects. you
haven't a clue what you're talking about, which is not surprising.

there are some cases where someone might work on a tiny piece without
knowing anything else about the rest of the project, but that's the
exception. the vast majority of software development doesn't work that
way.

typically, everyone on the team knows what the project is and which
piece they're responsible for (either individually or their team).

BTW are you aware that crash recovery
in some businesses is under five seconds?

that's long.

are you aware that it can unnoticeable, if designed properly?

The necessity for rapid crash recovery time depends on the function.

backpedalling.

Pointing out reality.

nope. you're pointing out a very narrow piece of reality, ignoring a
significant amount of it.

why would someone want slower recovery?

and most of the time that doesn't matter. consumer pcs and apps don't
have any crash recovery at all.

Irrelevant.

not irrelevant at all. most software is not fault-tolerant, nor does it
need to be.

you're the one fixated on fault-tolerance. it's needed in a small
number of cases, but that's about it.

When I mentioned custom programming, a business analyst, and
programmer/coder, you should have realized that consumer PCs have
nothing to do with the subject.

so why did you mention it then? this was about programming, not a
specialized scenario.

Although irrelevant to my point, I can think of several comsumer apps
that have a form of crash recovery. It's called automatic backup.
Let's try some common ones.
Excel,
Photoshop
WordPerfect;
Word. etc
Internet Explorer;

if you're referring to auto-save, that's not crash recovery.

the fact you don't know the difference shows just how little you know
about software.

In article , Tony Cooper
wrote:

I shouldn't slight the role of an accountant. All of what you said
above is true, but the accountant shouldn't let the share price affect
his decisions on the above points.

If you want to look at the OP's rather naif comment as a cash flow
problem, then the accountant might prefer regular feedings instead of
binging. I doubt if the OP is that aware, though.

(Reading back through the thread, chuckles) You get awfully hung up on
specific titles, specific numbers, etc. don't you, Tony? Does it help
if I just say "bean counters"?

The sole point was that the new marketing model, subscriptions, doesn't
necessarily serve the consumer or the people who develop the software -
not the people for whom the product is a labor of love. Subscriptions
serve the bean counters and the stockholders.. Consistent cash flow
leads to better predictions of revenue and fewer scary fluctuations in
stock price.

Oh, and my training was in accounting, and one of my jobs at
ComputerLand was accounting software consultant.