If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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 |
#12
|
|||
|
|||
Adobe goes into back-peddling panic mode
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 |
#13
|
|||
|
|||
Adobe goes into back-peddling panic mode
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 |
#14
|
|||
|
|||
Adobe goes into back-peddling panic mode
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. |
#15
|
|||
|
|||
Adobe goes into back-peddling panic mode
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. |
#16
|
|||
|
|||
Adobe goes into back-peddling panic mode
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 |
#17
|
|||
|
|||
Adobe goes into back-peddling panic mode
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. |
#18
|
|||
|
|||
Adobe goes into back-peddling panic mode
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 |
#19
|
|||
|
|||
Adobe goes into back-peddling panic mode
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. |
#20
|
|||
|
|||
Adobe goes into back-peddling panic mode
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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Camcorder: Works perfect in 0 LUX mode; Hazy in normal mode | Raqueeb Hassan | Digital Photography | 2 | January 9th 07 05:18 PM |
Windows Color Managment, Adobe Working Spaces, Adobe Gamma | Andy Leese | Digital Photography | 9 | November 24th 06 03:38 AM |
Adobe After Effects 7.0 PRO, Adobe Premiere Pro 2.0 for Windows XP, and tutorials, Adobe After Effects Plugins Collection (WINMAC), updated 19/Jan/2006 | [email protected] | Digital Photography | 0 | February 2nd 06 06:52 AM |
Can Adobe Photoshop save edited photos back to memory card?? | [email protected] | Digital Photography | 19 | December 13th 04 10:08 AM |