- you're half-way there - just chop off the other one, and you'll be equally proficient with both (for some very low value of "proficient").
Kind of like the guy who found Bizarro Genie, who grants only one wish, and it never turns out like you expect. He wished for "a schlong so long it would hit the floor" - so the Genie cut off both his legs!
I'm sorry, but that's totally bogus. Most people who owned a horse (unlike a sword, horses naturally reproduce) didn't own a sword. According to your theory, the majority would want to ride - or walk - on the "wrong" side to be harder to target.
The fact is that we don't know why some countries and cultures got into the habit of "everyone on the right" and others "everyone on the left" - but it has nothing to do with left- or right-handededness.
Try again - you have the right to depend on the public statements of people. Take a look at Oracle vs Google - Google is going to argue that the public statements of Sun CEO Jonathan Schwartz that Sun was just fine with Google Android preclude Oracle from successfully claiming damages, or that at the most they should be much lower because of this. Millions, not billions.
There's no stable ABI because the kernel developers, as a whole, decided they weren't interested in tying their hands for the sake of vendors that refuse to release open source drivers or vendors that refuse to push their drivers upstream.
Good way to cut off your nose to spite your face. It's not *just* the vendors who would have benefitted - users would too. But of course, that's of no import. What's the fun of a stable platform when you can be "free"?
The GPL is dying for a couple of reasons. It doesn't promote investment in GPL'd code, and its' #1 representative is a mysogenistic idiot man-child.
There's an easier way to get around the GPL - load an unmodified copy into ram, then patch it. Copyright only applies to software when it is in a fixed form, such as on a hard disk, or a DVD. This is why it is not a violation of copyright to make a copy of a program when you load it into ram.
So, no need to do a TIVOization to use a modified Linux kernel - just load the stock kernel, patch the ram image with your own proprietary code, and there's no obligation to distribute the source for either the patch OR the code that does the patching.
Nintendo lost when they tried to argue that Game Genie was making an unauthorized copy by patching code in memory - the courts ruled that the law simply doesn't apply to transient copies in ram, just to copies that have some modicum of "permanence."
The same loophole applies to ANY GPL code. Copies patched in ram are untouchable.
Also, it is the "forced got to give back the changes" that has resulted in too many forks, which is one of the reasons you'll never see a "year of the linux desktop." It's also why for most users even the latest linux desktops can't compete with 10-year-old XP - all the energy that could have gone into fixing the problems if there were only one or two distros has been dissipated (wasted) in generating a dysfunctional ecosystem of over 1,000 "me-too" distros. Plus, since there's very little opportunity to actually make money fixing the problems, they don't get fixed. Only a freetard will continue to argue otherwise when even Vista has more users, and works better. You know linux on the desktop sucks when you can't even GIVE it away.
It has its' place - on servers, in supercomputers, or with the fugliness hidden away under a runtime like Android, but that's about it.
His statements, as head of the FSF, can be used as a defense for any business decides to argue prommisory estoppel the next time they're sued for violating the GPL on all software copyrights assigned to the FSF.
Suppose that both you and your neighbor would find it useful to run a certain program. In ethical concern for your neighbor, you should feel that proper handling of the situation will enable both of you to use it. A proposal to permit only one of you to use the program, while restraining the other, is divisive; neither you nor your neighbor should find it acceptable.
Signing a typical software license agreement means betraying your neighbor: âoeI promise to deprive my neighbor of this program so that I can have a copy for myself.â People who make such choices feel internal psychological pressure to justify them, by downgrading the importance of helping one's neighborsâ"thus public spirit suffers. This is psychosocial harm associated with the material harm of discouraging use of the program.
Many users unconsciously recognize the wrong of refusing to share, so they decide to ignore the licenses and laws, and share programs anyway. But they often feel guilty about doing so. They know that they must break the laws in order to be good neighbors, but they still consider the laws authoritative, and they conclude that being a good neighbor (which they are) is naughty or shameful. That is also a kind of psychosocial harm, but one can escape it by deciding that these licenses and laws have no moral force.
The funny part - since he publicly states that neither copyright laws nor software licenses should have any force, anyone can pirate a GPL program and use his statements as promisory estoppel.
No wonder the guy eats his own foot cheese. He's nuts.
Also, the 2,000 pre-orders (included in the 82,000 figure) were cancelled by Amazon.
A friend asked me what tablets to look at, and I suggested the Transformer, as well as looking at the iPad and laptops. She ended up buyting an iPad and a laptop because, no matter how you put it, tablets suck for certain tasks, even "transformers".
Simply put, if you price it like an iPad, people will buy the "real McCoy", and opt for the iPad. That relegates Android to the bottom of the market. It's like trying to sell a linux desktop computer - except that you can't even GIVE the OS away because it's too fragmented and unstable for retailers to support, or for developers to target with proprietary software that will make them money.
There's a reason why everyone ends up distro-hopping. Even good distros "go bad" over time - witness the buggy KDE4.0 that almost killed OpenSuse, and their 12x update that ate user emails, slackware claiming "we're not dead yet" when in fact their main update repo has been down for a year, Mandrake/Mandriva one step away from a second bankruptcy, Canonical's failures to deliver a promised tablet for two years now - and still not making a profit....
Simply put, end users continue to believe - rightly - that they are better off with creaky old XP than with any linux distro. Same with tablets - they would rather pay Apple for something that works and gets updates than buy a potential orphan.
When that "one manufacturer" (two actually - both Dell and HP) are the #1 and #2 computer vendors in the world, it means a LOT.
The market is Apple iPad at the high end, Amazon Kindle at the low end, and everyone else trying to compete for the scraps that are left, which basically means the price pressure is such that they will never be able to "make it up in volume."
Google screwed up. They should have bought Motorola before releasing Android, and made it exclusively for Motorola. You'd have Googlerola Smartphones and tablets, and no issues with hardware compatibility.
Android is about to get a serious whack in the head from a completely unexpected direction - Valve. Valve is working on a full stack - linux+steam. Expect to see it on TVs (so forget the already-dead UbuntuTV), tablets, and handhelds.
They already have the content people want, a working app store, complete with drm that the studios will go along with for streaming movies, etc. - imagine no longer needing a game console to play games, stream netflix (or bypass netflix and/or hulu completely), surf the net, etc. People will buy that, in various form factors.
Manufacturers, given a choice between free Android, or Free Steam + a cut of revenues, will drop Android.
Is the Transformer nice? Sure - but the sales numbers tell a different story - people who look at it still end up buying an iPad instead. If they need a real keypad plus portability, they buy a laptop
You also can't compare android to an iPad - which is why Amazon sells more Kindle tablets than all the other Android makers combined.
In other words, there's the iPad, the Kindle, and "everybody else", which explains why manufacturers are abandoning the tablet market as unprofitable. Only the iPad can command iPad prices from the masses... because everything else really is a crappy, poorly-supported wanna-be knock-off.
But back on-topic - there is no way in H*** that RIM is going to survive - not by switching to Android, and not by sticking with QNS and hoping that they get any developer traction. The market has spoken.
Mind you, with the sorry state of Linux nowadays (fragmented, the desktop is a horror show, printer support for my "it says it supports linux on the box" is hit-or-miss - with the emphasis on miss, updates breaking things, having to distro-hop every few years, many major applications missing...) I've done my share of installs trying to get a usable desktop.
This week, after Fedora 16 messed up yet another update (after the OpenSuse 12.1 fiasco made me switch a few months ago), I went through Fedora 17 Beta, Debian Testing, Windows 8 Consumer Preview (first time I've installed Windows in a decade, but I'm really, really fed up with all the time wasted on "breakage" - and the Metro UI is awful), I've come up with something that "Just Works." Installed 2 optical drives, set my boot order to CD0, HD0, CD1, HD1, and installed XP, with Knoppix as a persistent image on/dev/sda1
So, when I want to book Knoppix, I put it in the first dvd, and "knoppix fromhd". When I'm done, just reboot.
It'll do for now... but after 15 years of using Linux, I see why most of my friends switched to Apple. "It just works" is worth a few bucks extra.
And how is Linux a "technology innovation" ? I could barely even install it a few times (and probably could not install it or get it to work more than a few times). I propose that the next award should go to Bill Gates for the Windows Installer (which I probably used a thousand times to install and deploy a working Windows OS).
You ran the Windows Installer 1,000 times to get a working Windows OS? No wonder you had a problem installing Linux. I'd give you the "Purple Flavor-Aid" award for persistence, but you've obviously already imbibed.
I keep waiting for the day when controlled burst EMP becomes the weapon of the revolution. My car is one of the few that does not even have an on-board computer.
By the early '70s, most cars had electronic ignition (even if they still had a set of points), which is also vulnerable to EMP. Also, your radio is vulnerable even if you have a diesel engine. And your 8-track tapes will be erased (and not only will nothing of value will be lost, but the world will be a better place).
Unfortunately, it's not going to happen. Testing and proper development cost $$$. The last couple of decades have seen an absolute explosion of crappy software from both proprietary and open-source vendors - but at least the proprietary ones have both the financial incentives and the means to do proper testing, and to pay people to do the stuff that nobody volunteers for.
Today was another example - printing envelopes using libreoffice under linux - it's more than 20 years behind the times. For me, it no longer matters - after almost 20 years of using open source, I'm done. My next computer will be a mac, because even if my time were free, my sanity isn't.
Open source has truly fulfilled the Peter Principle. I wish it were otherwise, but that's reality. It sucks, and I wish I hadn't wasted so much time and effort on it for so little return.
I feel your pain. I remember when Crystal Reports was a joke. Just goes to show, I guess...
On the "friends who bought PCs" - they could have returned the bundled printers and got that portion of their money back, plus a few bucks for their time and inconvenience. That's what small claims court is for, and if enough people do it, retailers will have to do a better job of informing their customers. If they can't be bothered, it's one of those "you get the government^Wretailer you deserve" things.
The same goes for people who buy machines with low-end specs and can't play the latest and greatest - you get what you pay for. As Heinlein wrote, TANSTAAFL.
The license management thing - maybe it's time for companies to actually demand that the courts enforce existing laws requiring that licenses be clear enough that the parties can actually know what they're agreeing to? It only takes one to stand up to the bully and bloody his nose... but I know, management will freak out and go "OMG they'll crush us!"
Not really - that's like saying that the building architects should have covered the placement of every single screw for attaching cladding to a building, every single nail that goes into every 2x4, and every single joint in every piece of piping.
The code is also a "reality check".
You can design down to the last implementation detail, in which case you're doing it wrong. You just have to hire experienced programmers who know what they're doing, not some outsourced 3rd-world contractors. It's cheaper in the long run.
The LInus quote wasn't meant to be the "untimate" definitive quote on the sorry state of the Linux desktop, btw. It's just indicative of how even people who use it all the time... well, it still has usability issues.
I had been using opensuse for years, having stuck with it despite the kde 4.0 fiasco... but it went the way of all distros on the last upgrade, totally crapware, and my choices, after a lot of looking around, were to either go to bsd (still tempting), go back to slackware (which is no longer supported between releases - the update site has been dead for a year now), on to mint (too much in flux) or fedora. Fedora won out, but even it had issues at first.
So there's simply no way that I can ever again recommend linux to anyone. Not unless they have an admin on site. You really do get what you pay for.
Now, on the question of your company's exploding licensing costs for proprietary software - have you asked for quotes from local developers on making a replacement at a more reasonable cost?
This process works because I'm not typically working to a "spec" (as indeed most of us are not these days).
And there's problem # 0.
People are too lazy to write a decent spec. Or, in so many cases, they don't even know how. Many have never even SEEN a proper spec. I've seen people who think that a bunch of screenshots is a spec, or that some database layout is a spec (though the latter is closer, but since it describes the actual implementation, it still fails). Or they'll spend a week with a UML tool, and produce something equally useless.
"SHALL", "MAY", and "NOT". A good spec is peppered with these. Not screenshots. Not general fuzzy descriptions. But too many people simply are intellectually lazy. They won't take a day to read a few real specs, and learn how to cleanly separate the specification from the implementation details, so they're locked into one channel of thinking before they even start implementing.
if you actually have to describe how to use the code, you quickly discover it's too hard to write about them all
If you have to code them all, you're "writing them all out" anyway. So, whoever has to write the spec should be equally willing to "write them all out" - or they're a problem, are not doing their job, should be called on it, and if necessary fired for incompetence.
A good example of the ongoing problems caused by incomplete and ambiguous specs is CSS 2.1. 15 years later, no two browsers render CSS 2.1 completely the same, because the original spec was a steaming pile of dog turd. It's why there are still so many additions being made to it to fill in ambiguities - and the back-filling process should never have happened.
This is what you get when you have a bunch of egg-heads in an ivory tower "assuming". Don't expect CSS 3x to be uniformly implemented in your lifetime - the process was never fixed, the guilty parties were never taken behind the outhouse and shot, and most people are still saying it's okay because "that's the way it is", same as programmers duck responsibility by calling it a "bug" instead of a mistake. I don't make bugs - I make mistakes. Only bugs make bugs.
You're not ever supposed to get into implementation details in a spec, unless it's to describe externals - such as an existing database or table that new stuff needs to work with.
The words "MAY", "SHALL" and "NOT" should pepper the initial spec.
1. Users MAY be logged in;// logging in is optional
2. Users SHALL log in before doing X;// only logged in users allowed to do X
3. Users SHALL NOT remain logged in for more than Y time before being re-validated.
4. Prices SHALL be displayed per unit, and per pallet;
5. Prices MAY include taxes;// this tells you that you'll need to do some research on taxes, locales, etc
6. Users MAY NOT have more than one session at a time;
None of this goes into implementation details; to the extent that you do, you have a bad initial spec - you're focusing on the wrong thing.
The logic, if it's not apparent when it's time to code, is a warning to step away from the keyboard, get a scratchpad, and THINK. Come up with at least 3 different ways to solve that portion, then pick one. Not just bang out documentation, test cases, and code until you have something that "sort of" works.
It's like the fundamental flaw in TDD (test-driven design). I'm all for DDD (data-driven design), but TDD encourages "let's fix this flaw", write a test for it, and if it passes, we're good. They forget to add 4 words - "until the next time."
TDD doesn't put the responsibility on the programmer to ask "what did *I* do wrong for this to happen in the first place, and what can be done to prevent it happening again?" Sometimes, it's an ambiguous spec. Sometimes, it's a badly thought out process - or an unnecessary one.
Case in point - bad user input. The typical TDD Agile Weenie says "I'll insert some code to make sure that they can't input a negative amount." WRONG! That doesn't solve 2 problems - the initial cause, which was that the spec should have said "The input SHALL always be an amount between X and Y", and that they coder didn't write a small lib that always forces values to be the right type and range.
Writing documentation in parallel is just a distraction; the same amount of time would have been better spent in quiet meditation about the problem and how to avoid it in the future.
So, next time someone delivers a spec, the programmer will look at it, redline the areas where no "Acceptable values SHALL be between X and Y", and send it back, so that whoever wrote the spec in the first place can fix THEIR mistakes.
Wrong. First you write the documentation, then you write the tests and then, if you have time, you write the code.
What garbage. According to that definition, if all that is ever delivered is docs and tests, you're good - whereas the reality is you've failed completely, since you have zero functionality.
The additional problem with test-driven design is that tests can only cover what you anticipate. But that's okay if you're a java weenie - you can point to all your tests and say "see, I'm 90% there already", because process is more important than working code.
The theory was, write the documentation, then code to the documentation.
In practice, that isn't sufficient to reduce bugs significantly, for several reasons.
1. As you develop something, you find that "getting from A to B" sometimes requires going via D instead of C;
2. Other times, you realize that the documentation doesn't completely capture the requirements, and you need to visit both C and D, and maybe Z
3. Still other times, you realize that A is entirely superfluous.
4. "Can you add/change this feature?"
The initial specification should never be too specific about implementation details - that's a mistake that too many people fall for, going with the illusion that they actually can nail down every detail of a non-trivial problem and just throw the spec at "code monkeys." They don't understand that a specification should only say what, not how. Writing "code documentation" before writing the code is writing the "how".
So they can end up with something that meets that spec, but doesn't work either as intended or just flat-out is wrong.
Unfortunately, code, then document (when and if you get around to it) is the reality because, unlike theory, reality is messy.
Slashdot Mirror
- you're half-way there - just chop off the other one, and you'll be equally proficient with both (for some very low value of "proficient").
Kind of like the guy who found Bizarro Genie, who grants only one wish, and it never turns out like you expect. He wished for "a schlong so long it would hit the floor" - so the Genie cut off both his legs!
The fact is that we don't know why some countries and cultures got into the habit of "everyone on the right" and others "everyone on the left" - but it has nothing to do with left- or right-handededness.
Try again - you have the right to depend on the public statements of people. Take a look at Oracle vs Google - Google is going to argue that the public statements of Sun CEO Jonathan Schwartz that Sun was just fine with Google Android preclude Oracle from successfully claiming damages, or that at the most they should be much lower because of this. Millions, not billions.
Good way to cut off your nose to spite your face. It's not *just* the vendors who would have benefitted - users would too. But of course, that's of no import. What's the fun of a stable platform when you can be "free"?
The GPL is dying for a couple of reasons. It doesn't promote investment in GPL'd code, and its' #1 representative is a mysogenistic idiot man-child.
So, no need to do a TIVOization to use a modified Linux kernel - just load the stock kernel, patch the ram image with your own proprietary code, and there's no obligation to distribute the source for either the patch OR the code that does the patching.
Nintendo lost when they tried to argue that Game Genie was making an unauthorized copy by patching code in memory - the courts ruled that the law simply doesn't apply to transient copies in ram, just to copies that have some modicum of "permanence."
The same loophole applies to ANY GPL code. Copies patched in ram are untouchable.
Also, it is the "forced got to give back the changes" that has resulted in too many forks, which is one of the reasons you'll never see a "year of the linux desktop." It's also why for most users even the latest linux desktops can't compete with 10-year-old XP - all the energy that could have gone into fixing the problems if there were only one or two distros has been dissipated (wasted) in generating a dysfunctional ecosystem of over 1,000 "me-too" distros. Plus, since there's very little opportunity to actually make money fixing the problems, they don't get fixed. Only a freetard will continue to argue otherwise when even Vista has more users, and works better. You know linux on the desktop sucks when you can't even GIVE it away.
It has its' place - on servers, in supercomputers, or with the fugliness hidden away under a runtime like Android, but that's about it.
His statements, as head of the FSF, can be used as a defense for any business decides to argue prommisory estoppel the next time they're sued for violating the GPL on all software copyrights assigned to the FSF.
The funny part - since he publicly states that neither copyright laws nor software licenses should have any force, anyone can pirate a GPL program and use his statements as promisory estoppel.
No wonder the guy eats his own foot cheese. He's nuts.
Also, the 2,000 pre-orders (included in the 82,000 figure) were cancelled by Amazon.
A friend asked me what tablets to look at, and I suggested the Transformer, as well as looking at the iPad and laptops. She ended up buyting an iPad and a laptop because, no matter how you put it, tablets suck for certain tasks, even "transformers".
Simply put, if you price it like an iPad, people will buy the "real McCoy", and opt for the iPad. That relegates Android to the bottom of the market. It's like trying to sell a linux desktop computer - except that you can't even GIVE the OS away because it's too fragmented and unstable for retailers to support, or for developers to target with proprietary software that will make them money.
There's a reason why everyone ends up distro-hopping. Even good distros "go bad" over time - witness the buggy KDE4.0 that almost killed OpenSuse, and their 12x update that ate user emails, slackware claiming "we're not dead yet" when in fact their main update repo has been down for a year, Mandrake/Mandriva one step away from a second bankruptcy, Canonical's failures to deliver a promised tablet for two years now - and still not making a profit ....
Simply put, end users continue to believe - rightly - that they are better off with creaky old XP than with any linux distro. Same with tablets - they would rather pay Apple for something that works and gets updates than buy a potential orphan.
When that "one manufacturer" (two actually - both Dell and HP) are the #1 and #2 computer vendors in the world, it means a LOT.
The market is Apple iPad at the high end, Amazon Kindle at the low end, and everyone else trying to compete for the scraps that are left, which basically means the price pressure is such that they will never be able to "make it up in volume."
Google screwed up. They should have bought Motorola before releasing Android, and made it exclusively for Motorola. You'd have Googlerola Smartphones and tablets, and no issues with hardware compatibility.
Android is about to get a serious whack in the head from a completely unexpected direction - Valve. Valve is working on a full stack - linux+steam. Expect to see it on TVs (so forget the already-dead UbuntuTV), tablets, and handhelds.
They already have the content people want, a working app store, complete with drm that the studios will go along with for streaming movies, etc. - imagine no longer needing a game console to play games, stream netflix (or bypass netflix and/or hulu completely), surf the net, etc. People will buy that, in various form factors.
Manufacturers, given a choice between free Android, or Free Steam + a cut of revenues, will drop Android.
How much did HP lose on their touchpad because of the "race to the bottom" for all non-iPad tablets? A billion is still a lot of money.
Dell abanoned their "Streak" Android tablet, and is now concentrating on Windows tablets.
Is the Transformer nice? Sure - but the sales numbers tell a different story - people who look at it still end up buying an iPad instead. If they need a real keypad plus portability, they buy a laptop
You also can't compare android to an iPad - which is why Amazon sells more Kindle tablets than all the other Android makers combined.
In other words, there's the iPad, the Kindle, and "everybody else", which explains why manufacturers are abandoning the tablet market as unprofitable. Only the iPad can command iPad prices from the masses ... because everything else really is a crappy, poorly-supported wanna-be knock-off.
But back on-topic - there is no way in H*** that RIM is going to survive - not by switching to Android, and not by sticking with QNS and hoping that they get any developer traction. The market has spoken.
It's not like Android is making much money either - Google makes $2 per phone, Apple $575.
And with the way that the Android platform has already fragmented, it's going to go the way of Linux on the desktop.
Want to buy an Android phone? Good luck comparing features, and figuring out if your manufacturer will even be offering updates 6 months from now.
All Android did was kill off Apple's other competitors, leaving the top - and all the profits- to Apple. RIM is just one more victim.
No - that's what they'll open their first private "genius bar" for.
It was a joke! :-)
Mind you, with the sorry state of Linux nowadays (fragmented, the desktop is a horror show, printer support for my "it says it supports linux on the box" is hit-or-miss - with the emphasis on miss, updates breaking things, having to distro-hop every few years, many major applications missing ...) I've done my share of installs trying to get a usable desktop.
This week, after Fedora 16 messed up yet another update (after the OpenSuse 12.1 fiasco made me switch a few months ago), I went through Fedora 17 Beta, Debian Testing, Windows 8 Consumer Preview (first time I've installed Windows in a decade, but I'm really, really fed up with all the time wasted on "breakage" - and the Metro UI is awful), I've come up with something that "Just Works." Installed 2 optical drives, set my boot order to CD0, HD0, CD1, HD1, and installed XP, with Knoppix as a persistent image on /dev/sda1
So, when I want to book Knoppix, I put it in the first dvd, and "knoppix fromhd". When I'm done, just reboot.
It'll do for now ... but after 15 years of using Linux, I see why most of my friends switched to Apple. "It just works" is worth a few bucks extra.
You ran the Windows Installer 1,000 times to get a working Windows OS? No wonder you had a problem installing Linux. I'd give you the "Purple Flavor-Aid" award for persistence, but you've obviously already imbibed.
By the early '70s, most cars had electronic ignition (even if they still had a set of points), which is also vulnerable to EMP. Also, your radio is vulnerable even if you have a diesel engine. And your 8-track tapes will be erased (and not only will nothing of value will be lost, but the world will be a better place).
Today was another example - printing envelopes using libreoffice under linux - it's more than 20 years behind the times. For me, it no longer matters - after almost 20 years of using open source, I'm done. My next computer will be a mac, because even if my time were free, my sanity isn't.
Open source has truly fulfilled the Peter Principle. I wish it were otherwise, but that's reality. It sucks, and I wish I hadn't wasted so much time and effort on it for so little return.
"Last time we contacted whoever owns them now"
I feel your pain. I remember when Crystal Reports was a joke. Just goes to show, I guess ...
On the "friends who bought PCs" - they could have returned the bundled printers and got that portion of their money back, plus a few bucks for their time and inconvenience. That's what small claims court is for, and if enough people do it, retailers will have to do a better job of informing their customers. If they can't be bothered, it's one of those "you get the government^Wretailer you deserve" things.
The same goes for people who buy machines with low-end specs and can't play the latest and greatest - you get what you pay for. As Heinlein wrote, TANSTAAFL.
The license management thing - maybe it's time for companies to actually demand that the courts enforce existing laws requiring that licenses be clear enough that the parties can actually know what they're agreeing to? It only takes one to stand up to the bully and bloody his nose ... but I know, management will freak out and go "OMG they'll crush us!"
Not really - that's like saying that the building architects should have covered the placement of every single screw for attaching cladding to a building, every single nail that goes into every 2x4, and every single joint in every piece of piping.
The code is also a "reality check".
You can design down to the last implementation detail, in which case you're doing it wrong. You just have to hire experienced programmers who know what they're doing, not some outsourced 3rd-world contractors. It's cheaper in the long run.
Thanks - I try.
The LInus quote wasn't meant to be the "untimate" definitive quote on the sorry state of the Linux desktop, btw. It's just indicative of how even people who use it all the time ... well, it still has usability issues.
I had been using opensuse for years, having stuck with it despite the kde 4.0 fiasco ... but it went the way of all distros on the last upgrade, totally crapware, and my choices, after a lot of looking around, were to either go to bsd (still tempting), go back to slackware (which is no longer supported between releases - the update site has been dead for a year now), on to mint (too much in flux) or fedora. Fedora won out, but even it had issues at first.
So there's simply no way that I can ever again recommend linux to anyone. Not unless they have an admin on site. You really do get what you pay for.
Now, on the question of your company's exploding licensing costs for proprietary software - have you asked for quotes from local developers on making a replacement at a more reasonable cost?
And there's problem # 0.
People are too lazy to write a decent spec. Or, in so many cases, they don't even know how. Many have never even SEEN a proper spec. I've seen people who think that a bunch of screenshots is a spec, or that some database layout is a spec (though the latter is closer, but since it describes the actual implementation, it still fails). Or they'll spend a week with a UML tool, and produce something equally useless.
"SHALL", "MAY", and "NOT". A good spec is peppered with these. Not screenshots. Not general fuzzy descriptions. But too many people simply are intellectually lazy. They won't take a day to read a few real specs, and learn how to cleanly separate the specification from the implementation details, so they're locked into one channel of thinking before they even start implementing.
If you have to code them all, you're "writing them all out" anyway. So, whoever has to write the spec should be equally willing to "write them all out" - or they're a problem, are not doing their job, should be called on it, and if necessary fired for incompetence.
A good example of the ongoing problems caused by incomplete and ambiguous specs is CSS 2.1. 15 years later, no two browsers render CSS 2.1 completely the same, because the original spec was a steaming pile of dog turd. It's why there are still so many additions being made to it to fill in ambiguities - and the back-filling process should never have happened.
This is what you get when you have a bunch of egg-heads in an ivory tower "assuming". Don't expect CSS 3x to be uniformly implemented in your lifetime - the process was never fixed, the guilty parties were never taken behind the outhouse and shot, and most people are still saying it's okay because "that's the way it is", same as programmers duck responsibility by calling it a "bug" instead of a mistake. I don't make bugs - I make mistakes. Only bugs make bugs.
You're not ever supposed to get into implementation details in a spec, unless it's to describe externals - such as an existing database or table that new stuff needs to work with.
The words "MAY", "SHALL" and "NOT" should pepper the initial spec.
1. Users MAY be logged in; // logging in is optional
// only logged in users allowed to do X
// this tells you that you'll need to do some research on taxes, locales, etc
2. Users SHALL log in before doing X;
3. Users SHALL NOT remain logged in for more than Y time before being re-validated.
4. Prices SHALL be displayed per unit, and per pallet;
5. Prices MAY include taxes;
6. Users MAY NOT have more than one session at a time;
None of this goes into implementation details; to the extent that you do, you have a bad initial spec - you're focusing on the wrong thing.
The logic, if it's not apparent when it's time to code, is a warning to step away from the keyboard, get a scratchpad, and THINK. Come up with at least 3 different ways to solve that portion, then pick one. Not just bang out documentation, test cases, and code until you have something that "sort of" works.
It's like the fundamental flaw in TDD (test-driven design). I'm all for DDD (data-driven design), but TDD encourages "let's fix this flaw", write a test for it, and if it passes, we're good. They forget to add 4 words - "until the next time."
TDD doesn't put the responsibility on the programmer to ask "what did *I* do wrong for this to happen in the first place, and what can be done to prevent it happening again?" Sometimes, it's an ambiguous spec. Sometimes, it's a badly thought out process - or an unnecessary one.
Case in point - bad user input. The typical TDD Agile Weenie says "I'll insert some code to make sure that they can't input a negative amount." WRONG! That doesn't solve 2 problems - the initial cause, which was that the spec should have said "The input SHALL always be an amount between X and Y", and that they coder didn't write a small lib that always forces values to be the right type and range.
Writing documentation in parallel is just a distraction; the same amount of time would have been better spent in quiet meditation about the problem and how to avoid it in the future.
So, next time someone delivers a spec, the programmer will look at it, redline the areas where no "Acceptable values SHALL be between X and Y", and send it back, so that whoever wrote the spec in the first place can fix THEIR mistakes.
What garbage. According to that definition, if all that is ever delivered is docs and tests, you're good - whereas the reality is you've failed completely, since you have zero functionality.
The additional problem with test-driven design is that tests can only cover what you anticipate. But that's okay if you're a java weenie - you can point to all your tests and say "see, I'm 90% there already", because process is more important than working code.
"agile" and "sprint" - two more myths.
The theory was, write the documentation, then code to the documentation.
In practice, that isn't sufficient to reduce bugs significantly, for several reasons.
1. As you develop something, you find that "getting from A to B" sometimes requires going via D instead of C;
2. Other times, you realize that the documentation doesn't completely capture the requirements, and you need to visit both C and D, and maybe Z
3. Still other times, you realize that A is entirely superfluous.
4. "Can you add/change this feature?"
The initial specification should never be too specific about implementation details - that's a mistake that too many people fall for, going with the illusion that they actually can nail down every detail of a non-trivial problem and just throw the spec at "code monkeys." They don't understand that a specification should only say what, not how. Writing "code documentation" before writing the code is writing the "how".
So they can end up with something that meets that spec, but doesn't work either as intended or just flat-out is wrong.
Unfortunately, code, then document (when and if you get around to it) is the reality because, unlike theory, reality is messy.