A print button? Mmkay. Let's explore WHY you need me to add that With all our attention on the Morlocks – down there with the whirring gears of Kubernetes and steaming clouds – it's easy to lose track of the Eloi: those concierges of productivity that smooth out the rough, upper crust of The Stack to make sure your software is actually usable. The trend now is to call this layer "design", …
I hope you guys are kidding. It feels like every project I've worked on which uses CSV as an input format has at least one developer (probably more, but at least the one who writes the CSV code) who writes a CSV "parser" by splitting lines on commas instead of using one of the many freely available libraries. I have just recently fixed *another* attempt to parse CSV data in this way, in spite of warning the dev team at the start of the project that you can't do that reliably. CSV has been around for long enough and is a simple enough format but people are *still* underestimating it!
Sorry, it's a bit of a sore point for me!
"Use Python, the library is built-in."
Somehow that doesn't stop them from reinventing this wheel anyway.
Another fun fact: if you try to import a .csv (which presumably stands for COMMA separated values) into Excel, you can select an arbitrary delimiter, and the default delimiter is not even comma (it's tab).
It's export, you have to change the locale to use a delimiter other than a comma. Then saving it as a ".csv" will correctly delimit it with pipes, semicolons, whatever..
There seems to be some weird hardcoding around the extension name - Excel can't actually process a CSV file with newlines in a text field unless the file is actually called blah.csv, which it will open without invoking the Import Wizard. Using a different extension name and going through the wizard ends up actually breaking the line.
Txs, I remember better now. Thing is, in previous versions of Excel you could actually set those options at import/export time, without putzing with the locale.
Which makes it quite annoying when they've taken that away for some unknown reason. One could always hope that it was to plug a possible security issue and harden Office, but, somehow, that seems unlikely.
CSV stands for Character Separated Values.
As for using a comma as decimal separator, I know Brexit and all but please take a peek over the parapet.
@Whitter: "comma [...] doesn't play nicely with CSV at all"
Yes it does! You just have to understand the format! Have a look at https://tools.ietf.org/html/rfc4180, it's not that long. TL;DR is that you can quite easily embed commas, double quotes and line breaks inside CSV fields but you can't read them back just by splitting on line breaks and commas, you have to parse the data character by character.
As you are writing ‘guys’ in plural it looks like you do not know that python has an included csv module. Additionally there exists ‘pandas’ library for python which also supports reading and writing CSV files.
In this day and age python can be expected to be either present or available on python.org .
Or are you referring to ‘cut’ / ‘awk’ only? In this case I have missed the joke.
@Prst. V.Jeltz
"So what do these modules do? how do they allow the data to have commas in it that dont end up getting used as a delimiter?"
They allow the data to contain commas (and line breaks, and double quotes) by using the escaping logic built into the CSV format. I gave a reference to it earlier.
The point is that the CSV format is not the simple delimited format which it first appears to be (and which is suggested by the name, which doesn't help). The delimiters (commas and line breaks) can be escaped, so you have to know the context in which they're being used.
A classic example being the Apollo 13 explosion.
Why? LOX tank exploded
Why? Because Kapton insulation was used on some of the wiring, which can explode.
Why? Because the voltage on that wiring changed from 15-->65v and no one altered the insulation thickness.
Why? Because the change control management system (paper based IIRC) failed to track the change.
Which tells you a) Bad things happen if change management control fails b) Checking the CMC system might find other errors, starting with any other areas that change was not made.
I requested a small UI change in some in house software once. In theory, simpler than a print button.
Four hours later still not fully done.
"Why would you want to do that?"
So the programmer is now responsible for designing the work flow procesess of the whole company? Is this what a "business anaylst" does? great work if you can get it - id love to be tasked with something like that ,and have the authjority of high up people to make changes. bliss.
We just get crazy requests from users which , unless they are monumentally stupid must be done.
we dont get to suggest the sensible efficint paper free methodology.
We cant even stop people buying printers and scanners in order to print stuff out so they can scan it in again.
And fax machines! will we ever be rid of them? Again anything people put through a fax these days was already digital 5 minutes ago but they printed it out so that they could fax it.
...and dont get me started on our "new user" process.(it involves handwritten biro)
"Biro? Six months ago I started using my italic fountain pen for the first time since my 20's."
Wow! You can write? manually with a pen? That'll make it easy to send secret messages that no one else can intercept. The security services must be wondering what to do if that ever catches on. How will they monitor everyone?
(Asimov dropped this into a short story, many, many years ago. Two school kids who learn the ancient art of reading and writing to send each other "secret" messages)
So the programmer is now responsible for ...
... for pointing out when a request appears to make no sense.
When some PHB asks you for a print button in a webpage, do you
(a) add a "print" button because you know no better
(b) add a button labelled "print", and surreptitiously check PHB's browser settings for what will work for him?
(c) point out that print is a browser function, and that to do it from a web page is at best re-inventing a wheel, and at worst a security hole (when someone compromises their own security so it'll "work" for them).
OK, the webpage is one scenario among many. In another case, the arguments might be different, and a sensible outcome might include the button. But I suspect that's not the kind of scenario where your programmer is pushing back against a request.
To give one example, if for example, the web page displays an invoice, then the print button would link to a page that displays just the details of the invoice, without any of the navigation links and other stuff that is currently displayed, or maybe to a nicely formatted pdf copy of the invoice.
Faxes: my paranoid little self wont let me email anything truly confidential like a social security#. But I'll fax it, after confirming the recipient is expecting it. Unprotected sitting around lifetime here is ideally minutes, not forever in email systems.
Because, as noted in the article, "people" don't always use software in ways the designer expected.
Fr'instance, I have heard an anecdote where a secretary used to intercept and print out all her boss's emails, and deliver them as a stack of paper on his desk, as that was how he had always worked.
Despite all the many initiatives designed to promote a "paperless" office, it's just not going to happen, untill perhaps tablets or phablets are completely ubiquitous and software is available to allow you to annotate any file as you go.
But for now, if I'm going into a meeting, I usually print out network diagrams, gantt charts, policy documents etc so I can scribble on them as they are discussed, and so do most of my colleagues.
So, why have a print button? Because most people will use it.
> Dinosaur
Thanks. I'm well aware of the myriad ways in which processes could be improved. However, right now, the only way $GovtOffice accepts submissions of this form is by registered mail, on paper, so if you could kindly STFU and add the print button, it'd be appreciated. Thanks!
/S, but only a bit sadly.
Dinosaur
Yes please! In a sesame seed bun, with onions, cheese, mustard, mayo and pickles.
And I'll take a 50 page document to go.
For some things, paper is better. I have 60-odd PDF datasheets on my pooter. The more important ones are in my paper info file, along with hard copies of certain bits of legislation and useful British standards documents. When I'm on the phone, and in a hurry, that file is what I flick through to get the right answers to the right questions without having to stop mid-sentence to make my computer find me the stuff I want.
Oh and it has the price lists too, with hand-written annotations.
I love my tablet, but even if I had a work one, I just don't see it being as fast to search as I can flick through a well-organised folder with dividers for the important sections.
"I love my tablet, but even if I had a work one, I just don't see it being as fast to search as I can flick through a well-organised folder with dividers for the important sections."
Yep, been saying that manuals turned into helpfiles. Not mention ebooks, reference ones in particular. They can be great if you know what you are looking for and the correct word is in the index or search results, but when you have something in the back of your mind or on the tip of your tongue, a manual flick through a paper book can far more quickly reveal the correct information. On a similar note, it's often quicker to flick through a book than to load up the help file or document, click the search function, type in the hopefully correct incantation and maybe get the right result, which is what IAS was saying. In other words, I agree with his pots!
The trouble with this sort of fanaticism is that some impressionable people will take it literally.
While I haven't printed a piece of paper in ages I frequently use various apps' print function to export a PDF file. This has saved me quite a bit of frustration. Yes, "design gurus", you need a print button. No, "design gurus", skimming through the book Design Thinking does not make you the greatest thinker since Aristotle. Understand what your users actually do.
I often print stuff. It's sad about the trees, but if I want to read a document through to see if it really makes sense, and to check for typing errors of the sort that a spell checker won't spot ( most of them) I need to read it off a page, not a screen. This may not be the case for the full time techie, or they may never have to produce such documents. But most ordinary users seem to read documents better from a paper, not a screen copy.
Yep, it is quite often the Dinosaurs in a company that want such features. The reason why they are still at the company is because they are often the owners or board members. So if the software is to be purchased, deployed and retained it better come with a print button.
"Why do you want feature X?" is always a really good start. All to often it's because they actually find it easier to do something by printing or exporting to CSV than doing it in the application where they're supposed to. Sometimes this is because it really is hard in the software, but often as not it's because no one ever showed them how to do it properly. Recent case in point: someone wanted a couple of extra columns in a report. They were in fact already available but no one had explained to this person how to change the displayed columns (and they hadn't thought to try right click on the column headings, perhaps because it's not the obvious design paradigm people used to the idea think it is...)
Agreed. Nothing at all wrong with asking a simple question.
Sometimes, the requestor just needs a bit of training to understand the requested feature is actually already available, perhaps in a slightly different form. Other times, the developer is enlightened to a use method not previously anticipated and the requested feature is worthy of addition. And then, every so often, one must patiently explain why the request cannot be granted because [valid reasons]
"Sometimes this is because it really is hard in the software..."
And sometimes it is because there are so many additional features stuck in the new version (Read Aloud, anyone? How about Resume Assistant?) that you have to drill down through five menus and preference windows to get to what used to be right in front of your face. Try searching for it online and you'll likely end up with correct instructions for the previous three releases, all of which are different and none of which are helpful. "Help" is good sometimes, if you can figure out what they've renamed the functionality you're trying to access. For example, I just typed "adjust kerning" into the "tell me what you want to do" box of Word (don't start) and it brought up the "compress pictures" dialog box.
Pfft, Mandarin doesn't even have gendered pronouns, or verb tenses.
Though probably only because they spent all that time coming up with the tens of thousands of symbols used for writing, so had to skimp on conditional grammar.
“Pfft, Mandarin doesn't even have gendered pronouns”
Not entirely correct; there are different characters for he and she, although they are pronounced identically. My Taiwanese girlfriend (who has lived in the US for >20 years) still occasionally uses the wrong one in speech.
... .application usability went down the sink because "designers" believe they "know it better", and enforce upon users silly and stupid design ideologies.
The Print button? Printing from any web application is still appalling - that's why the decent ones still generates a PDF and let the user print it through Acrobat. The others rely on the browser primitive functions, and print the whole UI together the needed data, usually reformatted in some ugly way.
Really, a breathtaking advancement in computer usability.... but you get in exchange silly animations and cool widgets you never understand if they are active or just there to show off.
You still need UI experts, not "designers".
"You still need UI experts, not "designers"."
Thank god, I was getting worried, almost at the bottom of the page and nobody had mentioned it. Although the article is giving proper designer a bad name I think, real designers are like engineers and make things work, stylists and marketeers have taken over the real designers' jobs, sadly.
I thought the other premise of the article that "this is what improves software over time" way off the mark. I have come across very little software that is actually better in any meaningful or productive way with every release. Still got the same bugs; more bugs introduced; familiar, de-facto standard, UIs re-arranged or stripped; lots of shiny added for no benefit; then the original, minimal and useful shiny taken away so you don't know which window is active.... I could go on.
I should have explained better my post - it's not "designers" - it's a subset of them, namely the "graphic designers" which entered the IT landscape when web development started to require them.
The issue is they never had to design UIs before, and they borrowed ideologies to UI design that really had no proper place. Just look at how they enforced monochromatic UIs removing useful visual clues - just because - and you worry that someone installed an Hercules card in your system.
or the new fully flat pastel design that again remove useful clues about controls, Z-order, etc. etc.
And let's not speak about web sites when all you get is an image half the screen size, with a couple of large clickable areas that should send you somewhere where you hope to find the information you need, but which are again very sparse because of the page design - form is now much more important than function.
That's what happens when you put people who should have been kept at designing brochures, in charge of designing UIs.
"... .application usability went down the sink because "designers" believe they "know it better", and enforce upon users silly and stupid design ideologies."
For years, the primary application I use in my job had menus down the sides, on a 4:3 screen, so there wasn't really enough width to show everything cleanly, but leaving unused space at the bottom of the screen.
Eventually, the app was redesigned such that all the menus were along the top, giving the full width of the screen to the useful data. Great! Except we now all have wide-screen monitors and all those fscking menus taking up vertical space means the useful stuff disappears off the bottom of the screen and there's loads of space at the side. Twats!
Keep your 'Print' button but someone, please, tell the designers that providing *usable* drop down menus on the interface would be oh-so nice---not the ones that contains hundreds and hundreds of items that you can only see three at a time and a scroll bar that contains no arrow buttons which forces you to try and view the list while it scrolls by at Mach 6 when you move the slider by one pixel. It's also be nice if you sorted the list alphabetically rather than puking out the items on the list in the order they came from the database.
(Don't get me started on stylishly-built web sites that include lengthy bits of source code presented in viewing windows/ports that make the code viewable only a few lines at a time and require that you scroll both vertically AND horizontally in order to see much/most of the content.)
rnturn,
Yes!!!
Yes, Yes, Yes, Yes .....
Oh! and BTW did I mention Yes !!!
It is not just Web Sites, some software has popup windows that cannot be made bigger to display Data that is meaningless in a Postage Stamp sized window !!!
The criteria for success seems to be not the usability of the resultant S/W but the fact that the ticklist of features has been all 'Ticked' !!!
Everyone thinks they can do UI Design, everyone has experienced 'Very Well Known S/W' that fails on this count and YET more and more S/W is created that is clever BUT totally unusable by people who need it.
Perhaps we should have a system that randomly switches off a useful feature in the Language/IDE that the Developers use for 'Every 'UI' Abortion' that is created.
If they are going to make my working day more difficult they should suffer too !!! :)
[Deep breathes ....in .....out ...in, take a 'Pink' pill .... aaaannnnd .........relax :) :) ]
"[Deep breathes ....in .....out ...in, take a 'Pink' pill .... aaaannnnd .........relax :) :) ]"
But that pill is only 'Pink' coz some designer spent months and millions of dollars figuring out which was the best colour, and the precise shade of 'Pink' for that specific brand of pill. Then a chemist spent many more months, and even more money, trying to figure out how to get those particular pills to be that exact shade of 'Pink'. After which it all had to be carefully explained to the colour blind PHB. A year later and the machines that make the 'Pink' pills, machines designed to a lower budget than the designer and chemist had, have drifted out of spec, and now produce pills that are various shades of kinda light reddish colour. No one noticed, or cared.
I know, I know, my 'Pink' coat looks green.
Why did a 5 minute job turn into a 2 month project?
- Because this is how we do things now.
Why?
- Because management have decreed it
Why?
- Because the devops consultant suggested it as part of a 30 minute talk that contained no other information or actionable suggestions
Why?
- Because the job of a devops consultant is to constantly churn a constant stream of buzzwordy goatcrap out of their mouths
Why
- Because that is how snake oil works.
"So basically a 5 minute job has turned into a 2 month project with "Digital Transformation""
Have you noticed how a religion starts with a guy coming back from a holiday in the desert and saying "Let's try being nice to people", and a thousand years later this has changed into big expensive buildings full of people in funny but expensive clothes telling their followers to go out and kill the heretics?
That's what happened in the days when you still had designer types, but they didn't have much to design.
Clearly, I don't speak DevOps.
Have an upvote for common sense. Tell me in plain English (or whatever language we can communicate in) what you want/need and why. I'll get it done. If it's a redundant function or a problem, we'll get a cup of coffee and sort it out. Certainly not 2 months worth of pondering the meaning of the universe and all that.
Mgmt: We need a print button.
Me: Why?
Mgmt: Customer asked.
Me: Do they print anything from there?
Mgmt: Don't know, they asked for a button
Me: Does it have to be a button?
Mgmt: Don't know, they asked for a button.
Me: Is there any chance of me speaking to someone to find out what they want?
Mgmt: They asked for a button, what else do you need to know?
Me: Errr, nothing I guess. When do you need the button?
Mgmt: End of the week.
Me: Hmmm, I've got to finish this, test that, and release that thing over there.
Mgmt: How difficult can it be to add a print button?
Which leads to the question, why doesn't my fucking software have a line of dancing monkeys!
Oi! Programmers! Get on it now! I want dancing monkeys whenever I send an email.
Actually we need to delete this entire thread - because someone might do that. This is an idea with the potential to make the MS paperclip look like a pleasant and useful piece of user interface design.
"Which leads to the question, why doesn't my fucking software have a line of dancing monkeys!"
Anybody else remember the screen sheep for NT4?
They actually had a use; getting IT-terrified people to use a computer is easier when friendly sheep walk upside down along the top of the desktop.
People will always find ways to do something useful -- from their point of view, anyway -- with your software/device/web-thingy by abusing some obscure edge-case behaviour. And then become dependent on it. And angry when it is fixed (obligatory xkcd).
This is often simply because using in an awkward manner a tool one knows is still easier/faster than learning to use something new. Whatever you make, it will be misused all the time. You should not design for misuse -- but you should expect it to happen anyway.
There's definitely merit in checking to see if what's wanted is actually what's needed - as the author notes, in this scenario, the user may just want to have an audit trail, or would be happy with an electronic copy.
However, what the author didn't note is that these options may require infrastructure changes, and are likely to require significant extra resource to implement, leading into a Dilbert-esque spiral of ever-increasing requirement bloat which chews up time and resources and adds little or nothing of value to the end user.
And indeed, that's sometimes the actual objective, as it means that some other department has to find the resources to deal with the implementation and/or argue with the end-user about it.
Not that I've ever seen that happen, nor am I still bitter about it ;)
Beyond that, and tucked away under the smug hipster-baiting fluff which padded out the word count, some of the statements in the article are potentially misleading. E.g.
"[a study] found that only a third of the features in their software were used as intended, or used at all"
This may well be true, but generally, each user uses a /slightly different third/ of the features; if represented as a Venn diagram, you'd end up with hundreds of overlapping circles.
Also, having lots of features makes sense from a marketing perspective; it shows your software is keeping up with the Joneses, and people like to know that if they ever did want to do <incredibly obscure thing>, there's an option to do so.
Then too, there's an old quote about how a good tool is something that can be used in a way that the original designer never dreamed of. It may not neither optimal nor cost effective, and it may offend your tender Eloi sensibilities to see your precious designs being casually violated, but if it's Good Enough, then people will use it. And therein perhaps lies a deeper lesson about the art of design...
> hey have to be strong enough
You might enjoy this (warning AvE so NSFW): https://www.youtube.com/watch?v=shnpPFQAugU.
Spreadsheet as database.
Once upon a time I used a fairly basic database programme. It was simple to set up and create tables and queries. Then suddenly relational databases appeared and the flat form ones seemed to vanish. Someone somewhere decided that we all needed these big complex beasts. Sometimes we do. But for a simple SOHO database with a few dozen, or even a couple of hundred items max it's overkill and a massive learning curve to use.
But often a spreadsheet will do the job perfectly instead.
Michael will be speaking DevOps at our Continuous Lifecycle London 2018 event. Full details, including early bird tickets, right here.
This was the point of the article. To tell you that the author will be speaking at a conference. He will speak for a very long time. No one will be able to decide if he said anything.
ebeer for your joke which was very droll indeed.
Now leave Yes alone. They founded a genre of music still being created by da yoofs of 2nd gen prog rock, and their albums still sell enough to keep 'em in press even though some of their oil paintings have worn through in recent years.
Revere the Old Wild Men. There are damn few of them left in the world arguing about musical differences and becoming tired and emotional in airports.
#I_Miss_George_Harrison_And_Alex_Harvey_And_Yes_Dammit_Chris_Squire
Way back in 2009, taking advantage of this methodology a famous Microsoft study (PDF) found that only a third of the features in their software were used as intended, or used at all. Think about all that fat in the other two-thirds that could be trimmed!
I remember reading about that study (I couldn't be bothered to read it at the time, but various summaries have found their ways in front of my eyes since)
It seems that the report was saying that any one user only used roughly 1/3 of the features, but that that 1/3 set of features was not the same across the userbase.
Therefore you cannot just wipe out 2/3 of your application and call it streamlining / removing bloat / technical debt reduction etc.
I stopped reading after 'DevOps'
Buzzword-laden marketing bullshit for stuff that a lot of us have been doing for years, albeit without excessive interference from damagement.
Plus, whoever came up with the term 'User Experience' should be strung up by the larger of their testicles from a tree in Rutland. I don't want an 'experience', I just want to get shit done.
I have to disagree. UX (in my mind) is there to keep the UI in check.
When designers are allowed to design the UI you end up with everything moving and (in the old days) driven entirely by Flash.
UX shouldn't be something you add - it's a stick to beat the UI people with when they get above themselves. The MS Office "ribbon" is for me a classic case of someone saying "this would be a cool UI" to which someone should have picked up the UX stick and beaten them until they could find the option for globally updating all trailing padding on blocks of monospace text.
There was no user story telling me why I, as a typical El Reg reader, needed to read this article.
It turned out that there was no reason for me to read the article. A long-winded, obfuscated article explaining why we should all oooh and aaah at the latest management fad (like user stories).
None of these management fads have any statistical justification for their claims (because it would be impossible to test). It's just anecdotal evidence (at best) and post-modernist waffling (at worst).
Because I want to print things. I do not care if you think that printing things is old-fashioned; I want to print things. I usually print things to PDFs and store them in folders in a nice hierarchial system, with the name of the PDF containing the date the thing was printed. I then back up the folders, so that the PDFs don’t get losted. Some PDFs are emailed to people who need to have access to the thing. On occasion I print to actual real paper; those copies usually go to [official idiot office] because they insist on actual real paper. On occasion I print to the fax function of the printer, and have [other official idiot office, which insists on faxes, not emails] print from the fax function of their printer. Or, perhaps, to the PDF creator function of their printer. I have a lot of PDFs. Typically, I print to PDF every time I order something, every time I get a reply from a vendor, etc; this adds up to a nice paper trail, especially as all PDFs are in a nice little folder named, for example, ‘Replacement Windows Desktops Order 15 Feb 2018’, and yes, that’s a real folder. Vendors have been known to ‘forget’ stuff; having their words on a nice PDF really helps Legal when they remind said vendors. Having the vendor’s words on actual paper really helps Legal if they have to go in front of a judge. Which has happened.
Now, get the bloody print button implemented. It should have been there in the first place, your product is not fit for purpose until it is in place as specified from the beginning. You have until Friday. On Monday your management will recieve a note from Legal, informing them that the contract has been terminated for non-compliance, and with your damn foolishness attached to show why. The penalty clause in the contract will be activated, and your company will owe us umpty-ump thousand dollars/pounds/euros, payable by the end of next week, or we’ll see you in court. And if you think that I am joking or bluffing, try me. And stuff your bloody DevOps bullshit up your arse.
Asking managers, remote from people who are at the workface what should be in a package and why will create an illusion that only dimly reflects what is needed. Your staff may need to print parts of the data your package produces so that they can wave it in front of a customer in the middle of a barn, or get a signature. They may work best by sitting in a group with pen and paper and scribbling notes on the hard copy. Anything. If the designer doesn't know why they are asking for the print button that just means the designer doesn't know how they do their work.They may not need a print button. But if you don't already know why they think that they need a print button it means that you don't know enough about what they do, whether you're right or wrong.
I have been using the Atom editor for several months before I wanted to print something, then I found out there was no Print... anywhere in the thing. After a bit of head scratching, I figured out I could export the code to Html, all pretty printed, and print the html with der bruiser.
Having actually written software that had to print, I can see the virtue in this. GUI means taking the whatever, rasterizing it, drawing it in a device context (yes, it was windows), and then handing that DC to the printer, hooking into the standard printer dialogs, wiring up a callback to cancel printing, and vast amounts of other fiddly code. Avoiding it would have saved months, and lotsa grief from customers with weird printers.
We are 40 years into the Paperless Office. About damn time to chop off the vestigial printers. And with the printers go the shredders and scanners and faxes and record storage boxes. Pile them up behind the building, pour kerosene on it, apply a match.
Programmers generally design interfaces (Web sites too) for other coders. These almost always are horrible for ordinary users.
Same is true of documentation and help files. The skills and attributes that are needed to create a good user interface are not the same as for writing code.
Why print? Because, barring a house fire, the binders of printed records will survive hard drive crashes, power surges, and bankrupt cloud services.
Yes, backups are good practice, but paper is static, doesn't change, and doesn't get corrupted or locked by malware.
It genuinely horrifies me to see small companies that have everything in the cloud with no thought to "How do I get my data back if the company goes bust, or if Google discontinues the service I rely on?"
"The skills and attributes that are needed to create a good user interface are not the same as for writing code."
There needs to be some overlap, otherwise your fabulous UI doesn't get the right job done. (Same with end-user documentation: If the author is one of those "professional tech authors" who doesn't know how the software works or what the user is trying to do with it, then the result is unlikely to be useful.)
Of course, "overlap" might just mean communication, and the communication might be 2-way. (I've certain known cases where I changed how a program worked in order to make the user manual easier to write.)
"Yes, backups are good practice, but paper is static, doesn't change, and doesn't get corrupted or locked by malware."
Paper isn't forever, toner and ink fades, some insects quite like eating or making homes out of paper, paper itself will fall apart if kept in a bad for paper type environment, or even if simply kept for long enough. Paper tends to burn easily, or the ink runs if it gets wet, both can happen during a fire. So paper does change, and does get corrupted, it's not static. Might not be locked by malware, but a two year old might grab some important paper from Daddy/Mummy's desk and scribble all over it with Daddy/Mummy's pen.
"This feedback loop, done weekly or even daily, is what improves modern software"
Or, to state the more usual case; This is the process by which a fit-for-purpose utility (eg MS Office) can be walked through numerous less-fit-for-purpose stages (eg menu redesigns) until it becomes completely unfit-for-purpose (eg The Ribbon).
The process of "enhancing" something until it doesn't work for anyone not on the design team is as old as electronic computing.
And "unused functionality" isn't always "excess fat", it's often the new process waiting in the wings for the users to adopt. If you are constantly designing products with features that no-one ever uses, you don't know your audience or its business requirements half as well as you think you do. In that case the problem is behind the drawing board, not the keyboard.
Back while working at a treasury department at a bank, it was fairly common for one analyst, in particular, to request a printed copy of some detailed report. Those printed reports would be directed to the humongous Xerox printer that inhaled a ream of paper in about ten seconds. Whoever assisted this analyst with the requested report had to babysit the process loading many reams into the beast to keep it fed while printing the typically two-foot-plus tall pile of paper. It was big enough that it was usually carted to the analyst's desk on a dolly that most people used for moving heavy equipment (a co-worker attempted to hand carry it one day and dropped the damned thing). The analyst would thank us for the report and then look at the /last/ page for the information he needed. I can't blame him too much for this tree-killing way of working---the application provided no way for him to get that information except via the printed report. Asking the vendor to fix that was probably a waste of time (had anyone in mgmt asked them) given that the vendor thought it was a nifty idea to require that anyone using the application have God privileges that the administrators knew better than to have enabled all the time---a nightmare that they refused to fix. ("Here's a letter to tell your auditors that it's required.")
"Think about all that fat in the other two-thirds that could be trimmed"This, for me, is the root of all the failures - the violation of "Make things as simple as possible, but no simpler".
Eventually someone always overoptimises The Tree, and snips off the brown ugly little-used thing connecting it to the ground that's obviously holding it back from getting higher. When you spend all your time pushing a boulder to the top of a hill, people can forget you're meant to STOP at the top.
We have multiple systems that used to be automated. They were replaced by Optimised Solutions. By which I mean, since nearly everyone only used the web interface, they no longer supplied automated interfaces, or if they did, they didn't *actually* work (because they didn't get tested properly (because almost nobody used them (because anyone who did found they didn't work))).
An action on one side of the company used to cause an effect on the other with no lag. Now, it has to go through multiple layers of humans, clicking on things, making errors, and only working a few hours a day. What took an hour, now takes a week. What used to be certain, is now uncertain. It's a beautiful Lego building, where all those ugly nobbles have been removed. More attractive, easier to assemble, but completely unstable on the larger scale.
The world is made from lots of 1%'s, not 99%'s. Averages give the wrong location for almost every individual. Trees need to go all the way to the ground. Always. Always. Always.
Most often heard from a system architect/designer type who already has a solution in mind. And some damned user has just asked for a function not provided by their pet solution.
Back in my day working at a little aerospace outfit just up the road from the Redmond Beast, we were trying to get a handle on knowledge capture from engineering documents. And basically trying to make the inputs as 'smart' and semantically parsable as possible. So we were recommending things like SGML schemas and tools that would support them. But every time we did, the MSWord fanboys would come back with "But why would you want to do that?" Mainly because MSWord's capabilities for generating structures documents was somewhere back in the Neanderthal cave-painting era. But they wouldn't ask us. They'd go two or three management levels above us and whisper the question in some ears. Whereupon, we'd have to explain (with PowerPoint pitch charts and a professionally scrubbed presentation) why we needed what we asked for. To people who only understood software and knowledge systems theory as far as PowerPoint and professionally scrubbed presentations.
"Could we have this article again, only this time written in English?"
Yes, BUT you would have to write another article to fill up the 'saved space' !!! :)
Perhaps, an article could be made out of this comment thread, it makes more sense and has a few 'Real World Truths' hidden within its many 'gems' [You know which ones if you read carefully !!!] :) :)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
