Forgot your password?

Who should have the most input into software redesigns?

Displaying poll results.
The users using it
  11305 votes / 52%
The engineers building it
  3298 votes / 15%
The UI/UX folks designing it
  1886 votes / 8%
The managers organizing it
  222 votes / 1%
The marketers selling it
  299 votes / 1%
The people who whine on the internet about it
  1941 votes / 9%
Leave my software alone!
  2593 votes / 12%
21544 total votes.
[ Voting Booth | Other Polls | Back Home ]
  • Don't complain about lack of options. You've got to pick a few when you do multiple choice. Those are the breaks.
  • Feel free to suggest poll ideas if you're feeling creative. I'd strongly suggest reading the past polls first.
  • This whole thing is wildly inaccurate. Rounding errors, ballot stuffers, dynamic IPs, firewalls. If you're using these numbers to do anything important, you're insane.
This discussion has been archived. No new comments can be posted.

Who should have the most input into software redesigns?

Comments Filter:
  • by chihowa (366380) on Tuesday April 16, 2013 @04:07PM (#43465561)

    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.

    • by thoromyr (673646) on Tuesday April 16, 2013 @04:13PM (#43465647)

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

      • 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

        • by jelizondo (183861) *

          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

          • by Macgrrl (762836)

            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.

            • by jelizondo (183861) *

              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, Insightful)

      by Anonymous Coward
      Although that sounds like a reasonable position - it is how we got Windows 8 Metro. A bunch of dilholes in a focus group were somehow lead by the marketers and UX people into saying that they wanted the same UI on their computer as they wanted on their tablet. Of course they didn't want that - nobody really does. The UX people told the engineers what to build and the engineers shrugged and built it.
    • I couldn't agree more. You need to know what the user needs - not what he says he wants. The IAs have to find the "chunky" spaghetti sauce. If you don't know what I'm talking about you must *MUST* see the Malcolm Gladwell TED talk on the subject of user preferences.

      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)

      by gadzook33 (740455)
      The iPhone was not built by asking users what they want. It was built by clever engineers solving a problem. Users don't know what they want or what is possible and there is no way to short-circuit or work around this fact.
      • Re: (Score:2, Informative)

        by ArsonSmith (13997)

        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.

        • by rvw (755107)

          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.

        • You do realize that inventions are based on integrating existing parts and not by spontaneously building something completely from scratch right? It seems that you are creating an artificially difficult litmus test to satisfy your personal need to downplay Apple's achievements.
      • 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

        • by gadzook33 (740455)
          No, lousy engineers are responsible for all that. The products we build are constantly praised by customers for their ease of use and simplicity of design because we spend hours worrying about every little detail. The problem is that you think UI/UX people aren't engineers. And no, the iPhone is clearly a hardware AND software product. Don't draw arbitrary lines around people or technologies, it won't get you anywhere.
          • 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.

          • by lgw (121541)

            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

        • by ADRA (37398)

          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

          • by Macgrrl (762836)

            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:3, Insightful)

      by tconnors (91126)

      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.

      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

      • by CHK6 (583097)
        Please append "Bad" to the start of your sentence and sprinkle in "backed by poor executive directives." There are some really great UX/UI engineers out there. Problem is there are equally as many bad UX/UI engineers as it's a soft IT position. Similar to that of graphic designers.
      • by lgw (121541)

        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.

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

      • 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)

      by mjwx (966435)

      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

      • by arth1 (260657)

        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

      • by Macgrrl (762836)

        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.

      • by jbengt (874751)

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

        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.

        • by jbengt (874751)
          Sorry for replying to myself, but I messed up the quoting.

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

          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)

      by Anonymous Coward

      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)

      by kramer2718 (598033) on Wednesday April 17, 2013 @11:51AM (#43473153) Homepage

      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.

      • by Kjella (173770)

        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

        • I am actually not suggesting that software engineers be allowed to decide WHETHER OR NOT a design is called for. Managers who have bug rates, outage numbers, and development velocity should be decide WHETHER to do a rewrite. Software engineers should decide HOW to do that rewrite.
    • by tsotha (720379)

      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

  • by sylvandb (308927) on Tuesday April 16, 2013 @04:10PM (#43465589) Homepage Journal

    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.

    • by pspahn (1175617)

      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

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

  • by pieisgood (841871) on Tuesday April 16, 2013 @04:29PM (#43465851) Journal

    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.

  • by guygo (894298) on Tuesday April 16, 2013 @04:39PM (#43465987)
    My 1-2-3 runs great on my 64k DOS system. I need nothing more. Leave it alone!
  • Users are morons (Score:5, Insightful)

    by gman003 (1693318) on Tuesday April 16, 2013 @04:57PM (#43466163)

    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.

    • You, sir, are a well-opinioned person. Can I hire you to re-design my software ? Scapegoat money included for when, not if, it all goes wrong.
    • by blackcoot (124938) on Tuesday April 16, 2013 @08:20PM (#43468017)

      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.

      • by ArsonSmith (13997) on Wednesday April 17, 2013 @01:34AM (#43469611) Journal

        Yes, find the pain points, automate them, get rid of the user. It's simple actually.

        • by Macgrrl (762836)

          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

      • by MacDork (560499)

        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 users, experts in their area of expertise, but not in yours. They often require at least some minimal education in what you do and why you do it in order to understand things like why "having more widgets and dials than a Formula 1 car" is a bad thing. They also need to understand something about the cost of what they're asking for. This is the truly hard part about designing computer systems; negotiating the specs. Anybody can bang out specs, anybody can bang out code that meets the specs. T
  • 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.

    • by dubbreak (623656)
      No. Marketing's job is to make tools for the sales people. They handle advertising and the presentation of the product to the masses. They don't design the product.

      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
  • Of course, an overwhelming majority of the voters here said "the users". Which is bollocks. Most of us are engineers, and our hands itch to do it an engineer's ways. Please prove me wrong.
  • by Anonymous Coward

    that shit for the next 10 years.

    • by barlevg (2111272)
      Indeed. They're the ones who can tell you the problems people are having and probably have the best instincts about what changes users will hate.
  • by bobstreo (1320787) on Tuesday April 16, 2013 @06:56PM (#43467313)
  • by GeneralTurgidson (2464452) on Tuesday April 16, 2013 @07:06PM (#43467401)
    m.slashdot.org [slashdot.org]
    • by sootman (158191)

      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.

  • The question is who should have the "most input". Not who should decide or implement things. Input. Surely that is the users who have direct knowledge, experience, necessity, and workflow to fit in with almost any software.

    At the redesign point, the users should probably be almost all the input unless you want a never-ending Office type software cycle.
  • by Green Salad (705185) on Tuesday April 16, 2013 @09:20PM (#43468401) Homepage

    Only HP Lovecraft's Cthulhu has input. I thought it was self-evident.

  • 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

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

  • whose job it is to listen to all of the above people and produce a coherent design that both meets the requirements and works.
  • 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

  • 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

  • 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 request features. They can point out flaws. In fact, most computer programmers can't design software well. Software design is hard.
    • Software design is easy. Creating an efficient and effective process is hard, no matter what type of design it is. You can teach some of that by helping to identify the components necessary, or creating rules about how specific types of components will be handled.

      But it still takes a person who is creative to put the components together in the most effective or efficient manner. (Yes .. those are sometimes mutually exclusive). Too many rules stifles creativity, too few rules allows for chaotic systems tha
    • Users obvious can't design software, but they can *drive* design.

  • Why can't it be just someone who actually knows what the fuck they are doing and understands the system. A bad engineer, UI, or user will always design a bad system except for that one time they get lucky.
  • ...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

  • 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

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

  • 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!

  • IMHO, if it's a redesign, it's for the engineers. Users won't care about a redesign ('It works now - why do want to change it?") whereas the people who look under the hood will worry about maintenance, support, performance. Refactoring.

    Of course, you still have to sell it to the users ... unless they're paying a 'support cost' to keep the wheels on the trolley, they'll baulk at the cost of a redesign where there's no new functionality. Maybe change the startup screen ....
  • The users choose, of course. (In the case of Microsoft, they beat the users into submission with a virtually unusable version of Windows occasionally.)
  • 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

  • by craznar (710808) on Thursday April 18, 2013 @06:19PM (#43487593) Homepage

    Users: What?
    Engineers: How?
    Managers : Who?

    UI: What colour?
    Marketers: How much?

    Whingers: The above is totally wrong.

Thus spake the master programmer: "After three days without programming, life becomes meaningless." -- Geoffrey James, "The Tao of Programming"

 



Forgot your password?
Working...