|
Simon Dufour wrote: If you do an app on your own, then choosing a solution like that is great.
If you have someone evaluating the customer need, then you're not the one to choose.
Exactly.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Which customer do you mean? The one you talked to yesterday or the one you will talk to tomorrow?
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
You're right. Each cases are different. If you don't know who'll use your system in the future, you have to predict their needs.. or at least, prepare for them. If it's your job, then fine! If it's not, then just make sure your code has an high enough cohesion to make changes easy and a low enough coupling to make some parts easy to replace or extend.
There's no magic. All I know is that the client is the one to decide what he needs. If you feel it's important for them, then sell them the idea.
Perhaps we should avoid to talk about "client" since a small part of us actually work for other kinds of apps that don't necessary have a known client.
Anyhow, if you ever have the choice to do it or not, the answer is pretty simple.
|
|
|
|
|
I'm going to agree with him, but I'd like to translate it a bit differently. It's not the customer, but the one who is responsible for the project that makes this decision. That's often a representative of the customer, for larger projects - or a senior developer from your own company if there's an anonymous product with a large userbase.
Point is that we mostly do what money dictates - programmers in a group, developers with a boss, hired employees can rarely make a strategical decision like this. Influence it, yes. Not make it.
I personally do not like the vendor-lock in that lots of applications and platforms bring. If it's my data, then I wanna be able to carry it around - but that's me talking as a user.
More people will be inclined to use your product if they can easily import their old data. That implies;
- You could get more users by being able to import a lot
- You'd loose less users if they can not export their data
I'm not judging whether the latter is a good idea or not.
I are Troll
|
|
|
|
|
We should not be required to, but we should anyways.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
We should develop our own standards and force everyone else to adopt our standards!
Sincerely,
Bill Gates
|
|
|
|
|
And you wonder why people call Microsoft a monopoly.
|
|
|
|
|
yes you should offer a web service and make all data public.
|
|
|
|
|
|
One can look at it as as the developers vote of confidence (or lack thereof) in their work:
If you're too afraid to allow your data to be exported, well maybe it's because you know the users will find something better.
My wife has to use some of that sort of turd-ware: the only way she can get anything like her work back is cut-and-paste from the screen. The application is amazingly non-intuitive, the site where the application resides will shut down for 'maintenance' at odd hours, and even making changes is an absurd route. Users universally hate it and the general consensus is that someone got a fine kick-back when they selected the junk.
So why not change? - because, as noted above, there is no piratical export mechanism. Eventually they will drop it - but the fees will be collected for a much longer time.
So - if you're deathly afraid your product can be replace by something better and cheaper, be sure to make export difficult or impossible.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
yes - let's publish salaries - or decrypted vouchers for air time ...
Yeee
|
|
|
|
|
? ? ? ? ?
What, exactly, were you drinking when you came up with that answer ? ? ?
? ? ? ? ?
Or, perhaps I hit a bit close to home!
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
If you work for a government agency you may be subject to a 'Freedom of Information Act' (FOIA) in which case it makes sense to plan on/program for exports from the start of a project (where time/resources allows).
IE: In Richmond VA a local newspaper obtained via a FOIA request the name, position and the wages of every state employee and 'published' this info on a searchable website (which may be what the respondent above was b*tchin' about).
GoodTime Charlie, VA
|
|
|
|
|
OK - for the moment, let's presume that your scenario was what he was referring to.
I still fail to see the relevance: The FOIA would exist, anyway, and they would have been compelled to give them the data, anyway. All that would have changed (maybe) is that they state had an easy way to give the required data (which they could have printed to paper if they wished, and still complied with the law).
The issue, as one would most commonly interpret it, is that one has an application which contains arbitrary data that is the property of the application owner (and possibly, the users). Should their desired use of their own property be inhibited or eased? Not having access to ones own property (and paying for the privilege) seems wrong to me.
A rather loose analogy would be that of a bank storing your deposits in 'proprietary' format so that you can't deposit them in another bank. Is a person's/business' data anything less than money?
Transferring the data will take time - and without a proper export mechanism, plenty of it. That unnecessary consumption of one's time (==life) is a very high cost, indeed!
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Your points are well taken.
My point was: If you know (or have good reason to suspect) that "your data" must be released in some form, planning for that release ahead of time can cut tremendously your expense to release the data (time, labor and/or materials).
FOIA was just an example of how you might know/suspect that data may have to be released.
And, of course, my choice of example of what was released was simply an attempt to offer a possible reason that the other respondent was so ticked ... ie: lots of us state workers in VA were really upset by the fact that we do not have the typical privacy one would expect from ones employer and a number of us are concerned about this info being released making ID theft easier, etc.
GoodTime Charlie, VA
|
|
|
|
|

I'm not totally separated from your situation of public availability of my personal information: I worked for US Dept of Energy for 11 years.
GoodTime Charlie, VA wrote: lots of us state workers in VA were really upset by the fact that we do not have the typical privacy one would expect from ones employer and a number of us are concerned about this info being released making ID theft easier, etc
It was long ago, but I went into public service knowing there are various trade-offs (lower pay, for one!). Another was being fingerprinted, and they did send investigators out to question neighbors about me. That's some serious intrusion. I don't know the extent of the info that VA released, but it shouldn't contain anything to substantially increase identity theft. Were I a betting man, I'd bet most employees have revealed more on FaceBook, and other such sites (none of which I belong to, neither do I tweet). Admittedly, in this latter sense, they did so of their own free will and accord. Some might even use gmail - which is, for someone concerned with privacy, insanity at its best . . . I don't even like send mail to gmail addresses.
This is more of a misery-loves-company note: In NY, the Dept of Motor Vehicles sells your Driver's License and Vehicle Registration information. You can opt-out of a lot of it - if you can remember to at the time and can find the opt-out check-box.
Maybe I can summarize my philosophy as simply the Golden Rule, as applied to software.*
* Perhaps why I never became wealthy
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It is a fantastic opportunity ! You are yourself a developer and you should have the capabilities to understand how things are stored in this application.
Create a program which export all data, and sell it to them, I dont imagine how they are willing to pay if more than 5 employees lose their time on this crappy software.
Don't you agree ?
|
|
|
|
|
The world is much uglier than that:
<ls>
Application is proprietary format - which, unless contracted contrary, will probably not become exportable or accessibleAdmins who selected the atrocity did not include the particular assistant principle who was supposed to be in charge of selecting the application - smells like a back-room deal*The input of data into such an application is not required by the teacher's contract, nor are they given any additional time to do what the extra work (they still must make hard-copies of lesson plans)
So, basically, the fix was in, that it doesn't work doesn't seem of any concern to the administratin, and the teachers are on the verge of rebellion (yesterday afternoon, apparently, it went snails-pace saves to not saving the work at all - much anger).
But, you're right. Admittedly in jest, I did mention to my wife to ask them if they want to contract a programmer and get an application that actually works. Perhaps, when they're adequately fed-up, they'll consider - but competing with commercial packages - and their perceived quality - will be quite a trick.
* they were fooling around with pension funds, until investigations started, so this is not so wild a speculation
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It's not easy to export in a wide range of formats. Many applications data format is both proprietary and subject to change - look at the various formats Word has used over the years.
How much time am I supposed to spend researching how to output in other company formats (when they won't give them to me) and how much time will my company give me to document our data formats for the outside world? Not a lot in either case, I suspect.
If there is a standard format, it does make some sense to output in it, but I think there will be pressure to make sure it doesn't work quite as well as "our" format - just to keep customers with our app...
Who responded other: "Bacon"?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
You can't possibly be offended by bacon. Bacon is the answer.
...but it wasn't me. I'm in the yes camp...
|
|
|
|
|
OriginalGriff wrote:
Who responded other: "Bacon"?
I so widh I could say it was me.
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
|
|
|
|
|
I have been beaten into allowing export from applications in the past. Problem is now the applications are nearly obsolete, but we can't turn them off as the exports from them are still needed. Also, we can end up with spaghetti linking between applications, rather than going back to a central point for data (eg SAP).
I tend to try my hardest to block these kind of exports. It reduces mainentnance in the long term.
|
|
|
|
|
By providing an import/export functionality, you will make it easier to transport your data to a newer application. Since your application is usually not capable of doing everything, sharing data is a simple way of making life easier for the customer.
of course, you don't want to have spaghetti-linked applications, but even linking them with some kind of ESB is better than no link at all. And who knows, you might want to merge two applications together later on, which can be done seamlessly if you allow exports.
Dennis
|
|
|
|
|
If I am ever writing an application that requires saving of data, I try to where ever possible save in an XML Based format using Serialization, its the eaisest way of doing it
|
|
|
|
|
Agree, nice and easy solution.
|
|
|
|
|