Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Digital Photography > Adobe goes into back-peddling panic mode

Reply
Thread Tools

Adobe goes into back-peddling panic mode

 
 
PeterN
Guest
Posts: n/a
 
      06-07-2013
On 6/7/2013 5:08 PM, Tony Cooper wrote:
> On Fri, 07 Jun 2013 16:32:30 -0400, PeterN
> <(E-Mail Removed)> wrote:
>
>> On 6/7/2013 1:27 PM, Tony Cooper wrote:
>>> On Fri, 07 Jun 2013 11:06:22 -0400, Scott Schuckert <(E-Mail Removed)>
>>> wrote:
>>>
>>>> In article <050620132227332978%(E-Mail Removed)>, nospam
>>>> <(E-Mail Removed)> wrote:
>>>>
>>>>> In article
>>>>> <(E-Mail Removed)>,
>>>>> RichA <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
nospam
Guest
Posts: n/a
 
      06-07-2013
In article <(E-Mail Removed)>, Tony Cooper
<(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
nospam
Guest
Posts: n/a
 
      06-07-2013
In article <51b248b4$0$10764$(E-Mail Removed)-secrets.com>, PeterN
<(E-Mail Removed)> 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.
 
Reply With Quote
 
Dale
Guest
Posts: n/a
 
      06-08-2013
On 06/04/2013 05:53 PM, RichA wrote:
> Whatsamatter? The pseudo-Marxist plot to turn America into a rental
> economy for services from an ownership economy not going down so well?
>
> http://www.nasdaq.com/article/adobe-...20130529-01017
>


manufacturing economy wins

--
Dale
 
Reply With Quote
 
PeterN
Guest
Posts: n/a
 
      06-08-2013
On 6/7/2013 6:48 PM, nospam wrote:
> In article <51b248b4$0$10764$(E-Mail Removed)-secrets.com>, PeterN
> <(E-Mail Removed)> 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
 
Reply With Quote
 
nospam
Guest
Posts: n/a
 
      06-08-2013
In article <51b324ef$0$10809$(E-Mail Removed)-secrets.com>, PeterN
<(E-Mail Removed)> 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.
 
Reply With Quote
 
PeterN
Guest
Posts: n/a
 
      06-09-2013
On 6/8/2013 7:58 PM, nospam wrote:
> In article <51b324ef$0$10809$(E-Mail Removed)-secrets.com>, PeterN
> <(E-Mail Removed)> 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
 
Reply With Quote
 
Tony Cooper
Guest
Posts: n/a
 
      06-09-2013
On Sat, 08 Jun 2013 21:50:34 -0400, PeterN
<(E-Mail Removed)> wrote:

>On 6/8/2013 7:58 PM, nospam wrote:
>> In article <51b324ef$0$10809$(E-Mail Removed)-secrets.com>, PeterN
>> <(E-Mail Removed)> 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?


That's an unkind and unfair accusation. nospam has extended his
research universe to include his dry cleaner, some people at a dog
park he walks by, and the entire membership of the local e.e. cummings
fan club. He is now accurate in his surveys to within 107 Standard
Deviations.


--
Tony Cooper - Orlando FL
 
Reply With Quote
 
nospam
Guest
Posts: n/a
 
      06-10-2013
In article <51b3df67$0$10793$(E-Mail Removed)-secrets.com>, PeterN
<(E-Mail Removed)> 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.
 
Reply With Quote
 
Tony Cooper
Guest
Posts: n/a
 
      06-10-2013
On Mon, 10 Jun 2013 12:39:56 -0400, Scott Schuckert <(E-Mail Removed)>
wrote:

>In article <(E-Mail Removed)>, Tony Cooper
><(E-Mail Removed)> 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"?


Yeah, I do get kinda hung up on word choice. To me, "accountant" is a
word that indicates the profession and "bean counter" is a
characteristic shared by people in several professions. A CEO may or
may not be a bean counter, but a CFO is almost always going to be a
person trained in accounting. CEOs who are bean counters tend to be
micro-managers because they dwell too much on the numbers and tend to
over-react to fluctuations.

>
>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.


I dunno about that "labor of love" bit. All those people listed on
the Adobe Photoshop splash page that developed the program may feel
rewarded by their efforts, but I'm not convinced they are all so
altruistic that they labored just for love.


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

--
Tony Cooper - Orlando FL
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Panic Mode: A Cautionary Tale Lawrence D'Oliveiro NZ Computing 15 08-06-2007 02:45 AM
Viewsonic n3250w LCD goes into unwanted standby mode mgriffioen@gmail.com Computer Support 6 02-22-2007 03:50 AM
Computer Halts During Boot... Hard Drive Light is solid and screen goes into "standby mode" a@a.com Computer Support 9 06-17-2005 10:56 PM
panic: GC failed to enter single threaded mode (possibly undetached threads? Tsahi Levent-Levi Java 0 08-15-2003 04:08 PM



Advertisments