Slashdot Mirror
Bad Software Runs the World
whitroth tips a story at The Atlantic by James Kwak, who bemoans the poor quality of software underpinning so many important industries. He points out that while user-facing software is often well-polished, the code running supply chains, production lines, and financial markets is rarely so refined. From the article:
"The underlying problem here is that most software is not very good. Writing good software is hard. There are thousands of opportunities to make mistakes. More importantly, it's difficult if not impossible to anticipate all the situations that a software program will be faced with, especially when — as was the case for both UBS and Knight — it is interacting with other software programs that are not under your control. It's difficult to test software properly if you don't know all the use cases that it's going to have to support. There are solutions to these problems, but they are neither easy nor cheap. You need to start with very good, very motivated developers. You need to have development processes that are oriented toward quality, not some arbitrary measure of output."
50% of all software is of below-average quality.
"Do you not know, my son, with how little wisdom the world is governed?" -- Axel Oxenstierna
Knight's problem was operations. Somebody pushed a test program onto a production network. That's not to say that software isn't hard. It is. It's just that system administration is hard too.
It's as simple as that.
Thanks to your hero Obama
http://washington.cbslocal.com/2012/08/08/papa-johns-founder-to-raise-price-of-pizza-due-to-obamacare/
How do you like that you looters?
FP. And what exactly do you mean by Quality???
That is because corporate infrastructure software does not generate revenue. Why spend money that does not directly impact the bottom line?
Maybe when you get people who actually understand the underlying business rather than a MBA graduate, that will change.
Good, Fast, Cheap...Pick Two.
With money and profit being the primary motivators, and these being directly related to the amount of time spent getting something released and generating revenue, there is no really good way to avoid this. (The software industry does not have a monopoly on this, either.) There are people within the organization whose primary function is to rein in devs who try to make every chunk of code completely bulletproof and spend hours, days, or even weeks trying to anticipate every sequence of events that could conceivably happen. At some point, you have to call it good 'nuff and move on, if you want to be competitive. If you're lucky, you'll be able to patch it later. If you're unlucky and there are errors to the point that the software is not usable, the company crashes and you move on. Everybody understands this game.
The underlying problem is that there are only so many people who really 'get' software development. Most of them are working in industries where they are compensated well or find the work exciting and interesting. Fixing legacy code on the cheap for a white-shirt-and-tie company like an electric utility or a defense contractor just isn't worth it.
True, most software is badly written and there are entire jobs dedicated to maintaining legacy and even current systems. Some software is so badly written that it requires a team to prop it during peak usage times or War Rooms to determine fixes. Managers usually only care about meeting a deadline and push for that. Young guys don't care about if something is correctly written - just that "it works" in that instance in time. Being a good developer requires being enabled to be a good developer by your team.
There aren't enough 'good' coders in the world to implement all the software that needs to be written, let along 'very good' ones. Not to mention good architects, designers, requirements analysts, etc, etc, etc. And even if there were, software that needs to work together isn't always designed to do so. Hacks, cludges, and jerry rigged solutions are what hold the tech world together, no amount of wishful thinking is going to change that.
That is because corporate infrastructure software does not obviously generate revenue, and losses of opportunity are invisible.
Fixed it for you.
Basically just supporting the last half of what you said.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
That's just mean!
That is so because the big boys are the first ones to have their development teams outsourced overseas, where a coder is made in 1 week from his previous shepherd job, and, i kid you not. Big4Style
"James Kwak .. points out that while user-facing software is often well-polished, the code running supply chains, production lines, and financial markets is rarely so refined"
...
I disagree, while the GUI may be well polished, the underlying code is of poor quality, as it has most probably written by some contractor on an hourly rate. Quality control works like this. If it compiles, ship it and fix all the bugs in the next version
AccountKiller
and this article is absolutely correct. Forthe most part, we do regression testing, but a lot of code (a whole lot) is never unit tested, its not written to be used it tested, and there are configuration holes all over the place. Each time there is a Jerome Kerviel or Nick Leeson, a generation of auditors will come through and find systems faults, and put in reasonably effective controls, but that is not the same as programmatic correctness. Programmatic correctness often has to be baked into the code from the start (same with effective unit testing), and by and large, this is not an investment banks highest priority (as an earlier poster wrote, code that is not directly involved in revenue generation does not get funded).
It isn't cost effective to build good software... for a few users. I develop some internal systems. They are very complex and each of them have 40 users at most. The ROI of Apple polishing every tiny bit of a software is great. If each of their 100000 users spend one second less, it is a ROI of more than one day. Human beings are very intelligent. They can learn to play a musical instrument, drive a car, operate a machine and to use shitty software.
OP mentions a few of the factors that help achieve better software (very good, motivated developers; orientation towards quality, etc). But the most important one was left out: customers willing to pay what it costs to get quality software, and their ability to spot high quality software up-front (during sales cycle). Until that happens, the quality will continue to be poor, because as OP notes, the cost will increase (driving customers away from higher-quality) and the lack of visibility to higher quality will keep them from getting it (ie, ability to recognize a better quality product during sales cycle and pay the extra price knowing they'll actually get higher quality out of it).
"You need to have development processes that are oriented toward quality, not some arbitrary measure of stupid."
XKCD:Xeric Knowledge Comically Dispen
I wouldn't say it's all bad software, I'm sure a lot of it is, but some of it is purpose driven software that has been repurposed as if it were off the shelf software. Dev houses build a piece of software for a specific need for a specific customer, then that customer refers them to others and they all want the same thing. They don't rewrite the software to be off-the-shelf, they just repurpose what they have and shoehorn it in and make it work(well, it works with MS SQL, but this company uses Sybase, so lets just quickly change the syntax and now everything is okay). It might be great software, but it's a shitty implementation of it.
... it is interacting with other software programs that are not under your control. It's difficult to test software properly if you don't know all the use cases that it's going to have to support...
You define the use cases it will support, and reject anything outside of those defined cases. If your software acts upon cases that it does not know how to handle, then it is your problem, and only your problem.
Perfection does not exist, as humans, we degrade over time and eventually die... Why we should expect software does not?
http://jameskwak.net/about/
So he has some actual experience with seeing the kind of effort it takes to do software with high quality.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Humans write software. Humans are inherently fallible, therefore the software they code is likewise fallible. Properly motivating a software engineer with pain or pay will not cause the engineer to become infallible. Removing greed from the equation might help, but like fallibility, it is in our nature and not likely to change.
Someone must figure that analogy is as complicated as the average Republican RedNeck can understand. Unfortunatly Shelley the Republican is no longer with us :)
Indeed. I've been parachuted in to several companies with major software issues.
Three had avoided even starting a migration from hardware and databases that hadn't been supported in a decade or more.
Another placehad no concept of file locking or threading, or QA, and was using 8 different programming languages on just one project.
Two companies that handled 80,000 to 300,000 transactions a day did not have any way of simulating input or comparing the input to output.
One company that depended on several million TCP/IP connections a day had no idea that TCP/IP data might not all arrive in one packet.
Another place whose business was dependent on several custom fonts would not believe the veracity of both the Postscript and TrueType font verifiers when they said "your font has 488 serious errors".
About 3/4 of the places had not a clue what SQL injection was and how they were vulnerable.
The quality of the stuff out there is just horrible.
The underlying problem here is that most software is not very good.
Wrong. You get what you pay for...news at 11
Writing good software is hard.
Wrong. Understanding the requirements and getting it right is the hardest.
There are thousands of opportunities to make mistakes.
Just like anything...people are fallible.
More importantly, it's difficult if not impossible to anticipate all the situations that a software program will be faced with, especially when — as was the case for both UBS and Knight — it is interacting with other software programs that are not under your control.
Actually, this was by design. Knight wanted a fully automated system and they did not want any user intervention at any cost.
It's difficult to test software properly if you don't know all the use cases that it's going to have to support. There are solutions to these problems, but they are neither easy nor cheap.
That's why they call it engineering. Do you think when they crash test cars and check to see how much damage will occur if you hit a cow? Of course not, because we stay within the bounds of accepted principles. We don't need to know the answer to everything.
You need to start with very good, very motivated developers.
It's not motivation that makes a good product.
You need to have development processes that are oriented toward quality, not some arbitrary measure of output.
Most development processes that are oriented toward quality use some arbitrary measure for output. The best measure is to see if it works.
Software isn't hard. Everyone constantly tells me so. "It's simple! All You Have To Do Is...".
"Oh, those preliminary mockup screens look almost perfect". So you'll have the entire system ready for production deployment next Tuesday, right?"
"Just git 'er DUN!"
That Lawyers and bloggers know about bad software.
Fugue for Aaron Swartz
Bean counter and management do. They don't care how much the staff struggles with lousy software (e.g. Oracle server on Linux). They care about saving a few bucks, getting their bonuses, reorganizing to hide the bodies and moving on to the next job. Hence, there will always be a market for crappy software. Capitalism fails at the interface level. If the engineers and low level end users made the purchasing decisions, you can bet quality would improve in a hurry.
Please do not read this sig. Thank you.
As a software developer, I have yet to hold a job where I felt as though I was being paid to produce quality software.
Me: "In order to implement the new functionality I've had to rewrite the entire module"
PM: "Ooooh, what's the SLOC?"
Me: "It's decreased by about 2000."
PM: "WTF?! How am I supposed to report that on my weekly metrics spreadsheet?"
When I first read the article, I asked myself "what is the meaning of 'good' software?" in the article and "what does good mean?". Then after I read through it, I found out that the article does NOT explain the meaning of "good" but rather generalizes that any software is bad if it "fails" to correctly serve even one of its purposes. All examples in the article are about money (of course). The meaning of "good" software in this article means "ideal/perfect" and "robust" software. I really doubt that any huge software could be even close to a robust software, leave alone the "perfect" part.
The solutions given in this article do NOT guarantee that a good software will be produced either. In other words, the "cost" of software implementation and qualified developers can only be used as an implication of software quality, but they are NOT the software quality themselves. One could spend billions of dollars and have all knowledgeble team, but could still get a crappy software even though it is unlikely. And even though the software is good, it could still fail under certain conditions (either by itself or being tampered from external sources -- hack -- or both).
Nevertheless, I like the conclusion of the article that the solution is to accept whatever might happen and attempt to reduce the damage done by software failure. That is what everyone should expect and be prepared for.
Which is better for code that runs won't-kill-anyone-if-it-fails systems like the stock market, airline scheduling, and the like:
Software that is delivered on time with a 0.1% downtime, a 1 per-1000 transaction "caught" error rate that leads to doing work over again or a reported failure, and a 1-in-100,000 transaction "uncaught until things get expensive" error rate,
OR
Software that is 100 times as good on every metric but which isn't delivered until 5 years after the "bad" version above?
For some customers, the first one is the better choice.
The problem with software is we don't have a good handle on how much delay or additional effort it will take to get from "definitely on time, maybe good enough, maybe not" to "definitely good enough, but very likely unacceptably late."
We also don't have a good handle on whether any improvements will introduce new problems or increase the odds of an existing problem being triggered from "almost never" to "often enough that people notice."
When you have systems that can kill people if they malfunction, the questions are the same but the costs of failure is much higher. When you have life-saving systems which can kill when they malfunction you have to trade off the cost of lives lost in malfunctions (medical radiation machines delivering overdoses) to the cost in lives of the machines not being available (cheap radiation machine not being widely available in the 3rd world for several years after it could have been if an occasional fatal malfunction in "version 1.0" was acceptable).
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
in our group save Li8ux from a where it belongs,
The way the article is written, it hints that low quality = more implementation flaws.
Let's not forget that software can have design flaws, too, and careful programming might still lead to low quality software.
In the case of Knight, the defects might not have even been a function of the software per se. I'm sure a good bit of probability and machine learning go into HFT; these algorithms may have been the source of the errors, and the flawed algorithms might not even be due to the software engineers.
while user-facing software is often well-polished
I think the distinction is that most user facing software doesn't lose 400million due to a bug.
love is just extroverted narcissism
If someone wants code that will work when honest, competent people don't try to "game" it and know where the holes are and avoid them, it can work well.
But as soon as you ask it to do something it wasn't meant to do, such as be used by someone who doesn't know where the holes are or doesn't know how to work around them, or someone who intends to poke at the holes and exploit them, then you are no longer using the code for its original purpose.
Think of it this way:
Assume my car works fine and "bug free."
Assume yours is too.
Assume our town's roads are bug free as well.
BUT the definition of "bug free" for a car implies that it will work as a transportation device only as long as competent, trained drivers who obey the rules of the road are driving. If I decide "hey, I'm going to see if my car can be exploited as a killing machine" then all bets are off. Likewise, if an untrained driver hops in and says "what happens if I turn the key and press the pedal on the right?" all bets are off.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Software is generally of very high quality. This guy has no idea wh500 Server Error\nConnection closed by client\n
I have used this program my entire career. For the last 20 years (since MSC bought PDA), it has not changed apart from the odd user-generated macro getting included in. The windowing interface has had the same bugs (e.g. scroll bars that are 1 pixel high) since I was a wee lad. Half the stuff in it that isn't used regularly doesn't work, never has, never will and yet it is the standard for FEM pre/post in aerospace. Staring at this broken-ass POS year after year has filled me with ennui.
May there be a special circle in hell just for MacNeil-Schwendler.
Thank you. That is all.
Equine Mammals Are Considerably Smaller
>> It's difficult if not impossible to anticipate all the situations that a software program will be faced with, especially when — as was the case for both UBS and Knight — it is interacting with other software programs that are not under your control. It's difficult to test software properly if you don't know all the use cases that it's going to have to support.
That's why so many industries continue to use FTP (also FTPS and SFTP) to punt files over the wall when real-time response is not critical.
File transfer is cheap, easy, and as long as at least one side hangs onto the files, reversible if someone makes a mistake. But most of all, it breaks up operational problems into two distinct parts: 1) did it transfer? 2) did it parse? From there, you can build help desk and other entry-level IT tasks to correct transient problems...and usually avoid having to hire programmers to maintain a potentially faster but more brittle tightly-coupled interface.
We have home-grown billing software here at MegaDyingCorporation. We've used it since the corporation was a wee little LLC and it will never go away. One of the things that is so attractive about this software is its interface.
It is green text on a black background.
It has no HTML-esq 3D fields to fill in.
It runs in a browser.
When rookie billers first see the software the thought most often expressed is "it looks so old" and then they are trained.
It is is difficult to learn
It has many obscure work-arounds
It has no in-line help
When rookies are trained there is no binder that says "do this and get that result," or "Standard billing practice requires you to do X and then Y and follow it up with Z". The rookies are trained by someone who knows precisely how to bill all of the accounts the rookie will be billing and knows that if the rookie goes off the beaten track even a little they will end up cleaning up after the rookie. Everyone trains. Everyone knows how to bill their accounts. Everyone has notes.
It runs in an old version of java
It cannot be updated
IT hates it with a passion
Accounting refuses to part with it.
The application takes the data from the account, marries it with the time-keeping data from another app, mixes it in with the services, and stock used and allows those who have been trained to produce any sort of invoice the customer wants.
It is hard to use like a blacksmith's hammer is hard to use. (or vi)
It is hard to learn like some martial arts are hard to learn (or some programming languages)
Once you learn how to use it the application has it's small flaws but those flaws are there to be used by others who want a different outcome.
It is a horrible, ugly, difficult to learn application that has driven more than one rookie to quit.
1) Ban all HFT software. Period.
Not a bad idea anyway, IMO, since HFT software tends to give the big fish an unfair advantage over, well, everyone else.
2) Tax the living shit out of all trades. When the day traders bitch, tell them to get off their lazy asses and contribute to society like the rest of us.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
The real problem is two things. People either not understanding the quality of the tools (software) they are using, or willingness to use "good enough" software and gamble against a catastrophe. Given the financial market's track record, it's most likely more of the second. If I have no idea about how to judge the ripeness of fruit and I make a pie that makes me sick because the apples were rotten, how can I blame the apples?
That being said, as a developer I can honestly say about 99% of the code I've seen is not Scottish. (It's CRAP!)
...is just good enough.
With the understanding that the world hasn't burnt itself down to a crisp thanks to all the bad software out there, the logical next step is to figure out just how bad you can write software with it still being good enough to run the world. Save the money and spend it on something else you think is more important.
You have "intelligent" confused with "trainable." If people were very intelligent, they would not be baffled every time an OS or application had a major UI overhaul.
The other day I was surprised wen talking about Debian to a friend. Debian is represented (misrepresented perhaps) as using only stable versions. This make so every new version of Debian is very rare. While other distros can live more on the cutting edge of tech and include more modern versions of all software.
He said that this is low quality. And I suppose kind of make sense. Quality can also be a attribute of delivery. Good code now is much better than the perfect code 10 years from now and having to pay 20 million dollars. For most uses, we write and use good code, and the perfect code is beyond what everyone need.
-Woof woof woof!
There aren't enough 'good' coders in the world..
Yeah there is.
Apparently not.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
All of the quality engineering, quality assurance, and quality control measurements should be designed to emulate the real world application of the software to the highest possible degree. Then a company must hire a compentent Quality Team in order to implement and perform the real world test cases. When it is not possible to recreate the actual real world environment due to cost or time, that risk is documented. Then management decides if it is an acceptable risk or if the money and time should be spent on creating that real world environment.
Sadly, they don't teach Quality Engineering as a focused career skill in school. It is always a secondary concern of development. Based on my own 17 years of Quality Engineering career experience as an individual contributor and as a department manager, about 2/3 of the developers I have worked with, are horrible at quality design, etc. That other 1/3 you find are the best developers in the company.
For every benefit you receive a tax is levied. - Ralph Waldo Emerson
Ah yes, the mythical good coder who writes it "right" the first time.
That's not really the work of a good coder. Anyone could get lucky, and no-one writes correct code all the time.
A good coder though can structure code in such a way that problems do not cascade, that incoming issues are limited in scope in terms of affecting the rest of the codebase. A good coder can make a huge system where you can replace a part of it without magic or too many tears.
Perhaps it's nothing more than the ability to think ahead a bit while coding or planning to code or pondering the data that is to be fed into a system, but from past experience there are simply many people who do not do that when coding or architecting for whatever reason.
For the non-coders out there, they kind of guy I am talking about is the pants tailor in "The Hudsucker Proxy", who added a second layer of stitching because he liked his client...
That's the kind of system a good coder gets you, the kind of system that lets you metaphorically hang by your pants 50 stories above the ground when things go pear shaped or your input goes wiggy.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
blame for the mess too hard to pin down to prevent recurrences by prominently displaying a few severed heads near the Tower of London.
That is so true. Not even "git blame" can lead you to the truth of who is at fault, when the problem is not that any one person is at fault as there is simply a failure to do something in a better way.
The problem with software is it's all to easy to get it working, but far harder to have it working a long time for any degree of shift in what must be done - and at the point something is working it's so hard to tell which variant of software you have....
There's got to be some kind of humorous measurement of what quality software you have based on what kinds of liquor are consumed on launch day by the engineers.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Be part of the problem.
Consulting. Minimum $100 an hour, right after you quit the first job you got out of college.
Is the distribution curve simmetric?
Why wouldn't it be measurable by the little people who live in your computer?
One company that depended on several million TCP/IP connections a day had no idea that TCP/IP data might not all arrive in one packet.
As long as all they cared about was opening connections then it doesn't matter how much data a packet could hold... :-)
But seriously, what you describe I'm pretty sure is common across most companies.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
why is this news to anyone? Software is -always- shipped full of issues to meet a PM's deadline in order to say "See!!! We got it done on time!" to justify their salary and existence at the company. "Ship it now and fix it after the fact" (if at all) has been the mantra of in-house and commercial software for 20+ years.
Fifty watts per channel, baby cakes.
quality entails
I totally agree with your list, but it also illustrates what an impossible task it is to know while building or at launch the level of quality of your software...
Look over that list, only this time with an eye to what you can actually determine about a system while you are building it, vs. years after it has been running:
architecture, design and implementation decisions that minimize the cost of change, that does not deteriorate with each change (or at least deteriorates linearly with each change),
You can have software that theoretically has this property, but here you cannot really know until the real changes come along. Very often the kinds of changes that must be made in reality, were not the ones planned for...
that exhibits strong cohesion and lose coupling,
This you can actually tell. So there's one.
that permits reasonable maintainability and configurability,
This depends on who is going to maintain it and administer it.
with relative small bug count per whatever metric one picks (FP, SLOCs, etc.)
I disagree with this point, as another poster pointed out there is a huge difference in kinds of bugs and the degree of pain they inflict, so a mere count is never a good metric of anything.
that is amenable for testing
Helpful but not in the end I think much of an indicator of the final quality of the software.
with architecture and design that are understandable (tied with #1)
Again, the measure of success here depends on who has to understand it going forward.
The real measure of quality in software rests on people that do not yet exist, and system changes that have not yet happened.
Given all that, the best you can do to build quality systems is to make sure at least some of your team are seasoned and trying their best to plan ahead for unplanned issues. AND that they are listened to when they have a bad feeling about something. When a guy who has built several working systems says he doesn't like something but can't explain why, don't argue - run screaming from whatever bothered him.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Remember: Broken gets fixed. Shoddy lasts forever.
Bad software also runs unimportant websites.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Weinberg's Second Law
I've worked in business software development for vertical markets (particular industries) for many years. It's full of incompetence both at the management level and the programming level. For example, a company will put out an RFP (Request for Proposal) for software that performs a particular task (e.g. managing customer orders in the gas industry or something) and it will consist of hundreds of pages of requirements that interested parties must fill out (does your software do X, etc).
What tends to happen though is that nobody wants to say no to anything in case your competitors lie. So everyone ends up saying yes, and either you quickly develop the missing functionality in some hasty half-arsed fashion or late in the day you basically say "We meant yes in the sense of no". These kind of shoddy practices distressed me initially, but eventually I came to realise that the whole industry was like this. Full of crooks and incompetence. Far shoddier than anything you would encounter on the shelves of a high-street software store.
Part of the problem is due to lack of funds, particularly in smaller companies. There often just doesn't seem to be the money to employ proper testing/quality assurance teams, so the programmers themselves end up doing those tasks. Also, due to money issues they end up employing inexperienced students instead of experienced industry professionals. The software managing your gas bills may well have been designed by someone straight from college who is still trying to learn C#/ Java etc. This is not uncommon at all.
So yes, the software suppliers are often unprofessional crooks but so are the customers. For example, there is a legal requirement (at least in Europe) that procurement of something over a certain cost has to go open to everyone. You can't just say "we want to spend £1000,000 on a customer management system from Company X. So the customer is forced to put out an RFP even though they have no intention of buying anything from anyone other than Company X. So software companies end up completely wasting their time filling out these RFPs. It can be really time-consuming and costly. So sometimes you make a judgement call that "this customer always buys from Company X, so lets not go through the costly charade of filling out their RFP".
It's quite a different world from that of developing Microsoft Word, or Google Docs etc. If you are in charge of software procurement at a company and you have to deal with this industry, you need to be incredibly cautious. As early as possible you need to demand to see demo installs of software to confirm that the RFP requirements are indeed met, and the companies concerned were not just lying through their teeth.
as Tiffany replied I am stunned that anybody able to profit $5569 in one month on the internet. did you read this site link makecash16.com
...
I'm not trolling, it's a reality check.
Most big software projects I've seen fail hard, like millions and 10's of wasted dollars hard. By comparison you just dont see that very often in big electrical/mechanical/civil projects, which can be equally complex (eg refineries, cruise liners etc).
There are software developers with all sorts of fancy titles - architects, analysts, engineers - and yet they cant get the code right. Usually the root cause is inadequete requirements spec and failure to manage the customers expectations but that's no excuse, there are usually numerous poeple employed in the project process specifically to get those parts right.
Software engineering is still playing catch up, in the sense that most developers and development companies I've seen still dont follow a formal enough process for it really to be called engineering. Usually it's a bunch of computer science graduates having a wild stab at it, and the good ones are closer to artisans than engineers.
Until the entire software industry gets off it's high horse and admits this to itself - and more importantly admits this to the customers, we are going to continue to be dissapointed with the quality.
Yep, it's mostly bad and made bad not solely by the programmers but by the business analysts.
...please keep producing crap software, as much as you can make.
Personally I earn a *stack* of money every year from clients who are fed up with your paltry offerings and want to get software from someone that knows what they are doing.
If the rest of you start doing a good job then I'm going to lose a lot of clients.
Sincerely,
One of the good ones.
Sooner or later the complexity we create will be too great for human intelligence to deal with. And not just in software.
E Proelio Veritas.
My back end and close-to-the-metal code is always much more solid -- and easier to write -- than UIs. I feel I'm much better at anticipating what a computer is going to do that what a user will try.
When it's on the Internet, it's either correct, or it's a catastrophic security failure waiting to happen.
Believe it or not, there are some industrial and embedded computers out there that are by design not on the Internet and in many cases, aren't capable of being put on an IP-based internet without major software changes and possibly even hardware changes.
Heck, most consumers own that will never be on the Internet, including some that could kill if they malfunction:
* Until recently, "smart" thermostats weren't able to be remotely accessed, but if they malfunction they can cause a house to get very hot or very cold, possibly killing a medically fragile person.
* Microwave ovens, which if the timer malfunctions can cook food to the point that it starts a fire.
* Automobile computers, which until recently couldn't be remotely accessed. If these malfunction, brakes can fail or be mis-applied, engines can rev, and other potentially deadly things can happen.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Here's a very plausible explanation:
http://www.nanex.net/aqck2/3525.html
And by now the psychopathic boss is standing by your cubicle, red in his face, pounding is fist into your cubicle wall, and YELLING: DELIVER! DELIVER! I WANT DELIVERIES!! NOT BEAUTIFUL CODE!!.
Well structured code does not have to be beautiful, it can be quick... obviously some structure suffers as a result but less than you would think.
Unlike Test First programming which imposes a huge up-front cost leading to exactly the effect you describe, simply writing well-structured code is something that is a skill you can fit into the most absurd of schedules to make the result better.
I have been on projects with exactly those pressures and still produced a code base that was suited for growth.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Forget corporate software, end-user software is just as bad. Consider something popular like ... I dunno, let's say Windows.
You see sloppiness every day. Things like:
# The file copy process. This remained basically the same from Windows 95 through to XP. Run into a locked or corrupt file? It kills the *entire* copy operation because of one bloody file, even if you were in the process of copying a thousand files. One uncopyable file doesn't mean all the files are the same way, this is just extremely lazy programming. Windows 7 has finally improved things a bit, but it still doesn't compare to far more usable replacements like TeraCopy (seriously, try it out, you will never go back).
# The command window. You are stuck with a very low maximum width. Why? Why can't I resize it to full-screen? Again, lazy programming.
# UI elements hanging on background processes. Open a network share, attach a USB drive, insert a CD, and what happens? Everything grinds to a halt, because the UI is waiting for something to load. Worse, it doesn't even provide any indication, it just locks up and you have to sit there and wait for whatever's holding up to finish. Lazy programming and lacking foresight.
# Internet Explorer, enough said (yes, IE9 is still crap)
I could go on, but I don't have all day.
And have not yet read this email! Though generally speaking I do not complain about it, I SUFFER IT. My search capacity in my own computer has decreased steadily from Win98 to this one. I can barely find anything now. I even feel like MS is like mimicking what I do while waiting for a team of programmers to advance it further... But anyway, compared to any other Human product, software manufature is still **on the making** and the least understood of all productive activities, though you have many experts who know why you are not as good as you think and what are your errors and how EXACTLY must be done, right?
1) It's like the old adage; fast. cheap, or good; pick two. If you're lucky. If not you get only one. Or zero.
2) Unlike other engineering disciplines where you have to pass a licensing exam, in "software engineering" there aren't established standards equivalent to the crush strength of asphalt or the melting point of tungsten which you have to at least know exist and can be looked up in order to be accepted as a real engineer in the chemical, mechanical, aeronautical, hydraulic, automotive, or whatever other real engineering sense. I wouldn't let a high school kid who taught himself mechanical engineering in his spare time design me a roller coaster; i know quite a few folks who should know better who had their cousin in high school who "taught himself computers in his spare time" design for them a billing system or inventory system or something of that ilk.
3) writing code is more like writing music. and there are general concepts which help you write good code just like there are general concepts that help you write good music. but writing a VBA macro for excel is a far cry from designing a pentode audio amp, to pick two tasks of approximately equal degree of difficulty, for those who are marginally facile in the relevant disciplines; like having a single course under the belt.
Star Trek transporters are just 3d printers.