Who should have the most input into software redesigns?
Displaying poll results.21544 total votes.
Most Votes
- What's the highest dollar price will Bitcoin reach in 2024? Posted on February 28th, 2024 | 8470 votes
- Will ByteDance be forced to divest TikTok Posted on March 20th, 2024 | 6336 votes
Most Comments
- What's the highest dollar price will Bitcoin reach in 2024? Posted on March 20th, 2024 | 68 comments
- Will ByteDance be forced to divest TikTok Posted on March 20th, 2024 | 20 comments
As much as it pains me to say this... (Score:5, Informative)
All redesign work should go through the UI/UX folks responding to the users' needs.
I strongly believe that form follows function, but without real consideration to how users will be using the software the user interface can seriously impede the actual function. Some engineers can be downright sadistic in their UI designs.
Re:As much as it pains me to say this... (Score:4, Insightful)
sounds reasonable to me. In reality there isn't a "single choice" the way a poll like this presents it, but I've had the misfortune of having to use too many "engineer designed" applications to want them anywhere near specifications or user interface design.
And the poll does say "software redesign" implying it is coming from an existing base. Features are worthless if they aren't used and coherent users can be invaluable in determining what would be useful to implement (unlike the seeming majority of incoherent users who think a bug report is "how to ask for usage help" or want the staples "that was easy" button implemented).
Re: (Score:3)
What is the alternative to "engineered designed" applications? Engineers are the only people capable of designing applications. Users and UI experts should definitely have input into the UI of the application, but UI is just one aspect of software design.
Do you remember all those windows 7 commercials where a bunch of users say "I invented windows 8" because it supposedly has a bunch of features that users wanted (i.e. that it was "their" idea). That's pretty much the limit of users input on software des
Re: (Score:2)
Yes and no.
Yes, most users don't have any ideas worth considering and as a software engineer one must come up with a reasonably efficient process. Most of the time, I spend hours/days/weeks actually doing the work (data entry, processing, whatever) in order to get a good idea of what needs tweaking or wholesale rewriting when designing a new system.
And no, because an experienced user can save me hours/days/weeks of work by simply telling me what are the shortcomings of the current system and what would be b
Re: (Score:3)
You don't necessarily want the users designing the system - but what you do want is to gather the business requirements completely and unambiguously. Capturing business requirements is a specialised role and probably shouldn't be left up to either the Software Engineer or the UI/UX people.
Re: (Score:2)
Dear Sara
As Billy Joel put it: "you might be right, I may be crazy"
But only if: a) you have a large enough team so that design/UI/business processes/programming, etc. is done by different people and b) the idiot mapping business processes actually can explain why paper "B" needs to be stamped at desk "11".
In the real world, if you want to do good design you don't ever isolate yourself from the business and the people actually running it, i.e., the grunts, not the Executive Director or Operations.
As Billy Jo
Re: (Score:3)
Why don't you download the latest iTunes from Apple's website? It doesn't sound like you're trying very hard to make it work. And I'm not sure why you expected any better of iTunes anyway.. it's always been a piece of shit..
Re:As much as it pains me to say this... (Score:5, Insightful)
Involve the end users in the design, but don't let them do the design or you end up with something like this [wikia.com]
Re: (Score:2)
As a BA whose main job at present is translating user change requests into software specification and requirements documents I would say the flow needs to go Business Requirements -> UI/UX design -> Software Engineer/Developer.
I constantly have to try and work out low impact ways of reverse engineering functionality into systems where the basic business processes have not been considered when the applications were designed - for example I've just been asked to include a way to charge for permits in a
Re:As much as it pains me to say this... (Score:5, Insightful)
I recently had the (mis)fortune of managing a small project from start to finish. Here's how it should have gone:
Business Requirements -> UI/UX design -> Development -> Review and Revision -> Implementation
Here's how it actually went:
Business Requirements (BR for brevity) assuming advanced (impossible) AI -> UI/UX/Dev meeting -> New realistic BR -> UI/UX/Dev mockup and approval -> Development Committments made -> Solution approved by UI/UX -> Implementation and Financial Committments made (with new BR "minor adjustments") -> UI/UX/Dev meeting to explain why BR "minor adjustments" are impossible with Implemented Solution -> Blame, paper trails, resumes updated, late night cowboy coding -> New Solution -> UI/UX/Dev meeting results in UI/UX "minor adjustments" -> Emergency Spagetti Coding -> UI/UX/Dev meeting results in UI/UX "minor adjustments" -> Much Balmer Peak coding, Terrifying Debugging -> UI/UX/Dev meetings results in UI/UX "minor adjustments" -> Spagetti code disassembled, rewritten for sanity (more late night Balmer Peak coding) -> UI/UX meetings finally result in a final stable Soution
I adamently wish I knew how to adjust the process so that the "should have gone" cycle would actually happen but there are hurdles I haven't found a way around because all too often:
Re: (Score:3, Insightful)
Re: (Score:2)
http://www.ted.com/talks/lang/en/malcolm_gladwell_on_spaghetti_sauce.html [ted.com]
Truly. The video is a must for anyone in software development.
Re: (Score:3, Insightful)
Re: (Score:2, Informative)
The iPhone was little more than first to market with emerging technologies. Cheaper LCDs, GPS, solid state gyros and multi-touch are really what made the iPhone. All newish or brand new tech not invented by Apple. Apple just supplied the early glue to put these things together. Very little invention involved.
Re: (Score:3)
The iPhone was little more than first to market with emerging technologies. Cheaper LCDs, GPS, solid state gyros and multi-touch are really what made the iPhone. All newish or brand new tech not invented by Apple. Apple just supplied the early glue to put these things together. Very little invention involved.
Hahaha! That early glue! It's true they waited until everything was small, cheap and good enough, but look at Windows Mobile and Symbian back then. It didn't compare on any level in user interface design. Just look at where Nokia and Windows are now - together holding eachothers hand, hoping they will survive.
Re: (Score:3)
Re: (Score:2)
And your attitude is the reason why most software products are shit in terms of UI, especially those intended for corporate users.
I have to use plenty applications with horrible UI which makes my work a lot less productive. The UAT usually consists of a couple guys clicking through all buttons to figure out whether they work.
I was part of UAT once for a large ticketing application and they provided us a SCRIPT to go through. I threw it away and came up with a document of 48 pages detailing all issues with t
Re: (Score:2)
Re: (Score:2)
Whatever UI is in an iPhone is not really original. Also, they had a pretty strong internal UAT and were lucky to be led by someone who knew what he was doing. If anything, the iPhone is an exception in a long, long, sad line of products which were built with no more than a shred of UAT.
Re: (Score:2)
ease of use and simplicity of design
These are often competing goals. One of the reasons I can't abide Apple UIs is their strong favoring of neat design ideas (how the device or screen looks from across the room) over actual usability. Heck, they explicitly admitted this at one point about the one-button mouse.
Good UI/UX people are designers, not engineers. Though design is an important part of engineering, to be sure, UX design is a full-time career, and a good UX designer needs to understand the 300 years of research behind good graphic de
Re: As much as it pains me to say this... (Score:2)
Re: (Score:2)
By and large, corporate software looks like crap because they can't be bothered to spend the real bucks to make it look good. You'd have to have a REALLY compelling cost breakown analysis to get something improved because quite frankly and ugly POS that does it's job DOES ITS JOB, and costs a hell of a lot less than a rewrite that has incremental productivity gains and a whole homp of a lot of risk. It sucks that you have to deal with poorly conceptualized software, but you're probably better off than suff
Re: (Score:2)
UI is more than just cosmetics. A properly designed interface can reduce user errors which can in turn make processes more efficient and reduce costs.
If you are describing an application as an ugly POS - what makes it ugly? Is it the colour palette, the configuration, the workflow? In some cases improvements in any or all of these can minimise user errors by making workflows more intuitive. It doesn't need to be all singing and dancing to do so, and simple charcoal on off white with a clean typeface can be
Re: (Score:2)
Well, there was a PoC release in 2010 for a certain product. We provided huge amounts of feedback. Then a year later UAT come and we realized all our previous feedback was simply not read. We presented huge feedback again, and no change was implemented in the end product. Now an awful amount of resources are being used to alter the product while it's in production, with patches and whatnot. Ironically, about 60% of what we asked in the first place were implemented post-go-live because some of the otherwise
Re: (Score:2)
About Windows 8 UI, I think it's simply a matter of someone with power (Ballmer or his acolytes) got carried away by what they perceived as an UI Revolution and simply chose to ignore all warning signs telling them "this road leads to perdition".
Re: (Score:2)
Well the same can be said of all phones regardless of manufacturers (e.g. Android Phones, Blackberry). This is what happens when you listen solely to marketeers and fanboys.
However the iPhone did ignite the smartphone market. Prior to its introduction, the skeptics were in full force naysaying yet another attempt to combine a PDA with a cellphone that will be dead on arrival. The iPhone surpa
Re: (Score:2)
Re: (Score:3, Insightful)
UX folk are why we end up with Microsoft Windows 8, the Ribbon interface, lack of menu bars, Gnome 3 and Chromium ("no, you can't have middle-click-selection-opens-URL-contained-in-copy-buf
Re: (Score:3)
Re: (Score:2)
UX folk are why we end up with ...
No, bad UX folk, who are fashion-followers not designers are why you end up with pretty-but-unworkable UIs. Which is still better than letting engineer design the UI - where you end up with a command line, command names as intuitive as "grep" and a help command intuitively named "man" (and search for help with "man -k", obviously!).
A good UX designer, with the opportunity for usability testing, is the best idea.
Re: (Score:2)
Windows 8/Metro is crap, Unity is crap, GNOME 3 is crap. Fair enough. But seriously, the ribbon is actually not really that bad. It's one of the few recent GUI redesigns that is actually pretty decent IMO. I do think that it doesn't belong everywhere though, and there are some times when it should just not be used over a traditional menu bar.
Re: (Score:2)
Windows 8: Marketing, not UX folk.
Ribbon: Marketing. MS decided to appease casual and new users over people who had a lot of time invested in the old UI (which, admit it, was a pile of shit with stuff hidden in dialog boxes four levels deep)
Gnome: Marketing.
Lack of menu bars: Idiots who believe non-standard UIs are good
Chromium: Marketing.
All too often, UX folk are shouted down by the ooh-shiny crowd.
Re: (Score:3, Insightful)
I strongly believe that form follows function,
You really need to look up this phrase.
It means a buildings appearance should be based on a buildings intended purpose (I.E. an apartment block looks like an apartment block, not a crushed coke can).
This is precisely why we shouldn't let UX people have the most say, because UX is a bollocks field invented by marketers to cover why their product was designed using principals contrary to well proven HMI/HCI. They beleive silly things like removing features makes user interfaces simpler.
but without real consideration to how users will be using the software the user interface can seriously impede the actual function.
This is what UX d
Re: (Score:3)
How to run a a product development project.
0. Get the users to tell you what they want.
1. Get the engineers to look at this and tell you what is possible.
2. Get the managers to look at what's possible and tell you what's in the budget.
Engineers are the most important. Everyone else will plan for the impossible to be magically done. Then managers because everyone else will plan for the impossible to be paid for.
That's very bad advice. What the customers want is something they will be truly unhappy with. See, customers aren't engineers (as in engineer, not software engineer) and seldom think further than first impressions. They don't know what bad things their wishes would lead to. It's not their job to think things through - it's their job to use.
What do the customers do is a better question. Add to that a dose of "what would and wouldn't they do if they could", and make sure you kill as many wouldn'ts as you
Re: (Score:2)
Let bad UX/UI take precedence, you end up with Windows 8.
Good UI/UX people - and they exist - don't believe in flash for the sake of it.
Re: (Score:2)
You really need to look up this phrase. It means a buildings appearance should be based on a buildings intended purpose (I.E. an apartment block looks like an apartment block, not a crushed coke can).
I believe it actually means that the building's structure and appearance should not be based on precedent, which could constrain how it could be built and used, but, rather, the building's service and performance should inform the building's structure and appearance.
Re: (Score:2)
You really need to look up this phrase. It means a buildings appearance should be based on a buildings intended purpose (I.E. an apartment block looks like an apartment block, not a crushed coke can).
I believe it actually means that the building's structure and appearance should not be based on precedent, which could constrain how it could be built and used, but, rather, the building's service and performance should inform the building's structure and appearance.
Re: (Score:2, Interesting)
UI folks?
I'm always amazed at how many people spend every day working with UI's that I've designed. Major corporations. Entire branches of government. All working with interfaces I pulled straight out of my ass. I'm an engineer. I know nothing about usability and style. Just look at the way I dress. Why would you have me design your UI?
It's really freaky to watch a room full of data entry drones working with a UI I wrote. They know it. They live it 40 hours a week. They can work it hyper speed wit
It Depends (Score:5, Insightful)
On the goal and nature of the redesign.
If the goal is to improve usability, then the customers should. Of course their input should be focused through the UI/UX guys.
If the goal is to increase profitability, then for B2C software, marketers and for B2B sales.
If the goal is to improve the maintainability and stability, then software engineers.
If the goal is to improve operability, then the operators.
If the goal is to improve scalability, then capacity planners and enterprise architects through the lens of software engineers.
Re: (Score:2)
I voted users, by which I probably meant "Are the users feeling it?" I mean there's plenty code that is cringe-worthy but that in reality doesn't matter to the user. For example I had one report I rewrote once that took 90 minutes, afterwards it ran in 8 seconds. But the only reason I did that was because I was trying to track down some faulty numbers - that it turns out the report wasn't responsible for, otherwise it was a report that was run once a month and nobody really cared that it took 90 minutes. Wa
Re: (Score:2)
Re: (Score:2)
I dunno. My impression of the UI people I've dealt with is they're much more concerned with how the thing looks (color schemes, rounded corners) and whether or not it follows the current fads (gradients!) than whether the users will be be able to use it effectively. I offer Windows as an example, which is a product that looks nicer and gets harder to use with every new release.
If you're developing an application you ought to know the use cases pretty intimately, so I don't understand how you can get in
Re: (Score:3)
And if PEOPLE can't use your SOFTWARE due to its garbage UI proves your point exactly how again?
"Software" is really a holy trinity:
* Understanding the hardware
* Understanding the art and science of programming
* Understanding the user experience
Now you can continue to be myopic if you wish but you are missing out on wholistic design and your software will suck compared to others who are looking at BOTH the macro and micro.
No wonder redesigns are such a problem... (Score:5, Insightful)
The only correct answer is "it depends."
What is changing?
Is it a UI/UX redesign? Then users and UI/UX experts.
Not user visible? Then the engineers building it.
New feature? Users and marketers but the engineers need input into the schedule/impact.
Managers if any, allocating resources and schedules are always involved.
Re: (Score:3)
Pretty much... yep.
I chose the engineers building it, simply because of personal experience.
When a client/customer says "I want a feature that will allow me to do X", it is mostly likely on the engineer to come up with HOW the software will accomplish X. Unfortunately, it is too often the PM or some other twit dictating to the engineer the best way to return X, which is probably why the redesign is needed.
If a plumber comes to your home because you've hired them to rebuild your pipes, who should have the
Re: (Score:2)
I can cover your hard costs...but your soft costs...I'm going to have to pay you for next time.
Re: (Score:2)
Why is there a toilet in my kitchen... we were on a time crunch and management said to only use the length of pipe we currently had available.
Plus it effectively doubles your I/O bandwidth, as your input and output processes can work in parallel. Efficiency win!
Re: (Score:2)
There is more to good UI design that simply the appearance layer. Good UI design should take into consideration the order events take place in, breadth vs. depth when accessing information, navigational relationships, confirmations vs. default actions, etc... All these choices can inform database structures and other underlying architecture decisions. Even something as simple as expected response times and whether something should show a progress bar is a UI decision.
Ultimately the UI is about communicating
Re: (Score:2)
I wouldn't say it depends on what is changing, but rather depends on what needs to change. If you're hearing major complaints from any of these departments, then it should probably warrant focus on that.
What kind of redesign? (Score:3)
There can be software architecture redesign, view redesign (user interface), Model redesign, ect.... In each case it really depends. Is it software architecture? Then let the software engineers make the call, is it a user interface issue? Let the designers make the call, is it a Database issue? Let the database guys handle it.
Re: (Score:2)
Leave it alone! (Score:3, Funny)
Users are morons (Score:5, Insightful)
If I'd listened to what the users *said* they wanted, I'd have a pile of self-contradicting systems, dozens of near-identical hardcoded reports, and a UI with more menu items than some restaurants.
If I'd listened to marketing, the front page would have more widgets and dials than a Formula 1 car, and we'd interoperate with every possible system, dating back to the 80s, and we'd have yet more repeated systems.
As it is, I have to creatively "forget" the stuff that management insists on that serves no purpose, and half of our features end up cut because they tell the site guys one thing, and the core guys another.
Oh, and because our UI guys never *use* the site, I end up able to design a better UI than they do. We started a complete redesign of the reports system, with some rather major changes, and the comp the UI guy came up with was basically the old comp with a few more fields (ironic, as one of the biggest complaints was that there were too many fields, many of which were not always needed).
What you do is *listen* to the users, then give them what they want instead of what they say they want. Placate marketing by making one of the new features more fancy-looking, with graphs or some shit.
Re: (Score:2)
Re:Users are morons (Score:5, Insightful)
You're asking the wrong question, as I've learned the hard way. The question you ask your users is not "what do you want", because obviously the answer is invariably "a pony and a cake and a million dollars and world peace." I've had much better success with "tell me about how things work today", which very quickly gets the conversation centered on pain points --- what is, from the user perspective, broken or otherwise less usable and friendly than it should be.
Re:Users are morons (Score:4, Funny)
Yes, find the pain points, automate them, get rid of the user. It's simple actually.
Re: (Score:3)
Yes, find the pain points, automate them, get rid of the user. It's simple actually.
You probably meant this sarcastically, but it's actually pretty close to the truth.
Systems are built to automate a process. You automate it to provide consistency in the outcomes for a given set of inputs. While you may not completely get rid of manual interactions, you can minimise them reducing headcount and costs. If your software introduces additional inconsistencies into the process due to poor design it will fail it's business case.
When looking for new features, reviewing pain points in the current pr
Re: (Score:2)
The pain points. They exist because of the current system design. The current system design is that way because of technical debt. Thanks to technical debt, those pain points are very hard to eliminate without a complete rewrite. So we end up at a rewrite, but everyone wants everything to work "the way it works today, but..." You can't change the database because there are 19 other apps written in several different languages that all depend on the database in its current form. As a result, the rewrite ends
Users are not morons (Score:2)
Re: (Score:2)
I'd also recommend Designing Web Usability: The Practice of Simplicity (1999) (ISBN 1-56205-810-X) by Jakob Neilson, who works for the same UI consultancy and Donald Norman. Both guys are quite insightful.
They may be utter idiots and pointless (Score:2)
They may be utter idiots and other pointless, but if it can sell, it's worthwhile. Maybe it really is the marketers we should be pandering to.
Re: (Score:2)
Should they have input? Sure, but generally it should be of the form, "We need feature X so that we have a bullet point that matches this competitor's bullet point." If you let them start dictating, "This button should be here and look like this.." you'll end up spending more time changing silly little things over and over than getting anything
Bad conscience, or professional conscience ? (Score:2)
The people who are gonna have to support (Score:2, Insightful)
that shit for the next 10 years.
Re: (Score:3)
And that's how we end up (Score:3)
with the Homer
https://www.youtube.com/watch?v=CpPuYGPcvD4 [youtube.com]
Here's an example of a bad redesign (Score:4, Informative)
Re: (Score:2)
Another: slashdot.org [slashdot.org]
When they took 'm' out of beta, they borked the styling on the story/discussion pages so they no longer render well on my phone. For a while there they were nicely-sized and I could read them OK; now they're super-wide so they get scaled down and are tiny. When I zoom in so the width of the invisible column is as wide as my screen, it's still too small. And, of course, m.slashdot.org discussion pages suck balls in general.
"most input" (Score:2)
At the redesign point, the users should probably be almost all the input unless you want a never-ending Office type software cycle.
Re: (Score:2)
Not who should decide or implement things. Input."
Like many here I have written a few apps in my time and no matter how much you think you know what the client wants, or how much better you know than the client, the fact is.. they have to eat that dog food every day and damn skippy they should have the biggest say in how it tastes.
Re: (Score:2)
I've cleaned up some awful messes that were built on those assumptions.
Only HP LoveCraft's Cthulhu (Score:3)
Only HP Lovecraft's Cthulhu has input. I thought it was self-evident.
Everybody but the managers (Score:2)
What drives the redesign? (Score:2)
Replacement of legacy h/w, s/w? That would be the engineers responsibility.
Regulatory compliance issues? Management and engineering.
Ease of use? Users, Internet whiners and UI designers.
Marketing can serve to pass user/customer requirements as they affect demand for the product. But once a need has been identified by them, its really the users who are calling for change.
There are times (I've been involved with a few) that some new technology arises (the Web in the mid '90s) which engineers are familiar
Missing option: The one paying for it (Score:2)
I'm missing the most important option: The one with the money paying for the software.
That's the one the vendors need to court, because he has the power to put money into the till. All the others are secondary. And this is also the reason, why I like open-source software so much. The mutual back-scratching between salespeople and purchase departments is disrupted by developer doing whatever they feel useful. Sometimes for very good effects, sometimes less so.
The software architect ... (Score:2)
The person who wrote the current version first (Score:2)
On the programs I built and then later rebuilt (was fortunate enough to work in a place where I was able to build and maintain systems over a long period), I probably put a lot more time and research in improving systems than the users had.
If it was left up to the users they would prefer the same thing with maybe a few new entries and features, because that's all they are accustomed to, not that is bad, but its not basis for good innovation.
As the developer I knew what limitations I had when I first develop
All of the above (Score:2)
System APIs: Software Architects, not coding monkeys.
Feature Set and Release Schedule: Managers
UI: Users (see also "people whining about it on the interwebs") and engineers (with minor help from UI/UX "experts")
Advertising: Marketing
The users, of course, but with a caveat. (Score:2)
This is a trick question.
The users drive the software; their use defines it and their input is the most important.
However, the users are their own worst enemy. They have trouble translating the effects they want into the designs that are required in the software.
Thus I think the users need the most input, but that needs to be filtered through developers, the smart managers (1-2% on any job), and the user experience folks.
That is, if you want functional software. Users are their own worst enemy and are self-
Users can't design software. (Score:2)
Re: (Score:2)
But it still takes a person who is creative to put the components together in the most effective or efficient manner. (Yes
Re: (Score:2)
Users obvious can't design software, but they can *drive* design.
Who cares ... (Score:2)
The engineers, but... (Score:2)
...Developers aren't the only software engineers on the team. Everyone forgets the test analysts. Input from the test team can improve design for testability considerably, making everything from unit tests to migrations and BI much more straightforward. A lot of developers tend to see testing as a sleight on their prowess and completed documentation as a tedious imposition. I have a tendency to believe that developers with that attitude typically have no prowess worth mentioning.
Yes, I'm fully aware that
Sorry, what was the question? (Score:2)
This isn't a simple question.
It depends on the purpose for the redesign. The engineers probably have the best insight into correcting code & data inefficiencies.
Many people should probably have input on usability & functionality redesign. The UI and engineering people need a deep understanding of both how the app is currently used and what the goals of the app are in order to make the flow efficient. Most people resist change that will add efficiency -- accelerators in GUIs, changing the keyboard
Why is it being redesigned? (Score:2)
Who is in control would depend on why the design is being done.
Not cpu efficient, put th engineers in charge.
Not usable, put the UI people in charge (real UI people).
Not selling, put the users in charge.
Never put managers in charge. Never put marketing charge.
Glaring omission: IT DEPENDS (Score:2)
Are your current customers satisfied, but too small a base to turn a profit? Did your research team screw the pooch on their last market analysis? Did your engineers uncover a fatal flaw in the design? Is it a rebranding redesign or are you addressing fundamental problems?
Need more input!
"Redesign" is the clue (Score:2)
Of course, you still have to sell it to the users
Users Pay the Bills. (Score:2)
ReDESIGN or ReENGINEER? (Score:2)
I don't like the question because it's too vague.
Same code (few tweaks) but new LOOK? A GOOD UI/UX person who actually has spent time reading the millions of dollars of research done by big companies like apple, MS, motorola, nike, etc ... creates a design based on original user feedback ... and then gets feedback from a good random sample of users to tweak the new design.
New Code (Aka: Re-Engineer) - Engineers should have first dibs to create a list of current features, outdated features, new technologi
What/Why/How etc... (Score:3)
Users: What?
Engineers: How?
Managers : Who?
UI: What colour?
Marketers: How much?
Whingers: The above is totally wrong.
Re: (Score:2)
Re: (Score:2)
Why do you hate poor people? and really it's way more than 1% that pay 10 percent or lower (as in zero) taxes.
Re: (Score:2)
"...the lowest income households, the elderly and young working families with children." (howstuffworks.com)
A large portion of those are net tax consumers, such as $81,000 in this case http://www.whptv.com/news/local/story/Living-the-good-life-off-of-government-benefits/OcplDUaU202odM47mcbdvg.cspx [whptv.com]
Since the net tax is negative, your claim is grotesquely untrue.
Re: (Score:3)
How the hell are you a "friend of a friend" in my relationship status? Seriously, you embarrass me and I'm not even sure who's responsible (other than you, of course) for that.
I'm not posting AC. Screw it.
Seriously?
Re: (Score:2)
Marketing are the guys that are trying to convince people that their product ( or at least the hyped up version of their product) is the one they want. They are often the guys who know the least about what the users want AND about what their product is actually capable of doing.
Re: (Score:2)
In the corporate world marketing has two separate and distinct functions - one is attempting to make their product attractive to the market in order to increase sales; the other is to research and predict market direction in order to inform where R&D funding should go in order to create desirable products. These functions both live in the Marketing Department but are rarely done by the same people.
Re: (Score:2)
disregard above comment (Score:2, Funny)
argh...tabbed browsing!...I meant this comment to go on this thread: http://politics.slashdot.org/story/13/04/17/0238209/obama-administration-threatens-cispa-veto-eff-urges-action [slashdot.org]
Re: (Score:2)
Not for my application. It's ultimately payed for by my users' bosses' bosses' bosses allocated out of their budget. And the money for it comes from my users' productivity. Where they know what will benefit productivity, we do what they ask.