Feeds

back to article Software sucks these days - and just maybe it's all YOUR fault

Every now and then, I write a blog article that could probably get me sued, sacked or both; this started off as one of those, and has been heavily edited by myself to avoid naming names. Software quality sucks. The "release early, release often" model appears to have permeated into every level of the IT stack; from the buggy …

COMMENTS

This topic is closed for new posts.

Page:

Silver badge
Paris Hilton

Say no to Beta grade stuff?

Well that excludes just about everything that comes out of Redmond, WA.

The latest window patchs are a prime example. 125Mb... most of this is IE-9 and .Net V4. Buggy software these guys release without a doubt.

Paris bacause she just loves watching herself on 'Betamax'.

0
11
Gold badge

CSC

Corporate Stable Code. Outside of Redhat - and maybe IBM - we're going to get that kind of commitment where?

0
0
Silver badge

First of all ...

... There is no such thing as "software". So-called "software" is the current state of the hardware.

My hardware runs better today than it did thirty years ago.

Your "slow software movement" is more properly called "kit that works".

I suspect your real issue is with marketards pushing kit that is broken by design ...

0
17
Anonymous Coward

Re: First of all ...

I think you need to upgrade from the valves and gears kit you're currently running

8
0
Anonymous Coward

@AC 08:06

Oh, I don't know. Steam punk is enjoying quite a resurgence lately.

3
0
Anonymous Coward

Re: First of all ...

There is no hardware. Once you know this, then you'll see it is not the hardware that runs, but yourself.

3
0
Anonymous Coward

Re: First of all ...

Nice try. Since you don't understand what software means to IT people, please stop posting. You're not likely to post anything of value. As indicated by past posts.

5
2
Silver badge

I find it amusing ... (was: Re: First of all ... )

... that none of the AC[1] replies to mine seem to have a clue as to my meaning. I also find it sad. Seriously, kiddies, there is more under the hood ("bonnet", to you Brits) than "apps".

[1] I also find it amusing that all replies are AC ... :-)

0
2
Anonymous Coward

Re: First of all ...

"My hardware runs better today than it did thirty years ago."

Lucky you, mine needs Viagra.

...oops, wrong hardware

0
0
Anonymous Coward

Totally

I'm plenty disgusted by vendors who don't even release a changelog and upgrade your servers without telling you, breaking your business. Thanks wankers...

2
0
Gold badge
Facepalm

"...the amount of fundamentally broken code that has made it through to us is scary."

There's an easy explanation for that.

Back in the day, your code would have been written by someone who a) knew the language it was written in, b) knew the system it was targetting, c) had a basic understanding of the problems and processes it was meant to address and d) knew what was and was not good practice in the environment it was written to run in.

These days it'll have been written by some clueless graduate in India who knows Java, has had a two day cross-training session and been given a spec relating to something he's never heard of.

The think the bugs are bad? Try looking at the code......

16
0
Anonymous Coward

Re: "...the amount of fundamentally broken code that has made it through to us is scary."

I had a job doing software reliability testing but when I tried to apply the standards of quality and repeatability I had been drilled in when testing hardware I got shouted at as it made the product look bad since it got lower performance numbers than the previous version. When I re-ran the tests on the previous version using the same methodology it showed the new version was much better, but apparently that was even worse as it made the previous group of testers look incompetent.

The sad thing is the code was actually good, just the testing methodology was geared towards marketing rather than engineering.

Anon....because the code really was good and I don't want to upset them

7
0
Anonymous Coward

Re: "...the amount of fundamentally broken code that has made it through to us is scary."

Another problem is legacy, code where I work has gone through various iterations. Starting out with MINT code, then had C built on top of that, then C++, now C#. We have tools built in Eiffel and VB, we've started using XML.

Each time a new language is added, our coding standards seem to have changed, the old code is effectively abandoned and left in a state of limbo, with much of the code untouchable, not just because it's the core of the program, but because the person who coded it used the strangest of coding methodologies deliberately overcomplicating things so that they couldn't be easily replaced, only to then quit.

The original code is now over 20 years old and it still holds up the back end. All we've done is put bubblegum and paperclips over the top to keep it held in shape. And because we're only software in what is mostly a hardware company management won't really accept the resource drain to redo this legacy software from scratch. So we're stuck patching up fixes which we can't actually fix because doing so would break several other things.

5
0
Bronze badge

Re: "...the amount of fundamentally broken code that has made it through to us is scary."

Spare us the historical fantasies. I've been a professional software developer since the late '80s, working in a variety of areas - mostly system software, with some application and some embedded work, on platforms ranging from PCs (and expansion cards for them, hence the embedded development) to mainframes. There have always been lousy programmers.

Yes, software is a bigger industry now, and that's dragging in more unqualified staff. That's part and parcel of the other factors Glassborow identified: increased complexity, market forces that encourage frequent releases and discourage testing, the declining cost to manufacturers of providing fixes. But there was no golden age when all programmers were competent, and certainly not one when they were all sages who could produce code every time that was free of "fundamental" errors and fit for purpose.

0
0
Bronze badge
Facepalm

Ah...

So you've seen the Firefox update cycle then too? :D

I'm sticking to a 6 month or yearly update on FF, devs be damned!

3
0
Bronze badge

Re: Ah...

So you've seen the Firefox update cycle then too? :D

Seriously, man... I'd just gotten settled in with Firefox 4 when suddenly, I turned my back for a minute, and they were up to version 7. And, what are they at now... version 14, something like that.

That's just nuts, man. What the hell are they thinking?

1
0
Alert

I'd offer an explanation that it's the exponential growth of computing power that has made developers sloppier in their approaches. Whereas once upon a time, they had to watch every resource used closely, and not following best practice led to programs that failed to run entirely, now we're in a situation where "good enough" code runs and error handling routines pick up the slack.

Additionally, the comercial drive where companies have realised they can make money if they constantly sell to new customers, and care little about retaining or placating the old ones, then there's less financial pressure on the developers to fix anything other than the most critical of bugs, and instead they become focused on developing new features for the software instead that look good in a sales demo

6
0
Holmes

Ask to see the design documentation ...

For any major upgrade where you are spending non-trivial amounts of money, ask for the design documentation. In most hardware companies they can probably so you something. In most software companies they probably look shifty and mumble something about having Doxygen for the APIs.

Most of this stuff is heavily stateful, probably has had threading bolted on as an afterthought, security toss in at the last minute for a good measure, and I can guarantee that 95% of it has never gone near any form of design review board at any point in its life. Writing code isn't hard, designing software which works unfortuantely is. In most places the "powers that be" don;'t view design as valuable, and get twitchy when the code line count isn;t going up fast enough.

It's like complaining a civil engineer doesn't turn up on day 1 and starting to drive piles for a skyscraper. "Hey mate, that looks a bit wonky", "Don;t work we'll sort it out after release".

4
0

software sucks because the sales people arent selling any software

just their jumped up notion of brand identity and other such nonsense. any actual product that gets made is incidental.

3
0
Thumb Down

Re: software sucks because the sales people arent selling any software

As a software sales person, I can tell you we just sell whatever crap comes spewing out of the dev team. If its utter tosh or amazing we dont get a say, just a big Sell this amount of this or look for another job...

If its good we can sell it based on what it does and how it does it.. If its crap then its all bout the branding and marketing.

Which is the same in all markets, ever wondered why LV bags look so plastic cheap but yet sell for hundreds.

Because suckers always buy into brands...

2
0
Silver badge

Are users to blame? We are a lot more accepting of poor quality code. We are used to patching everything from our PC to our consoles, cameras and TVs, especially those of us who work in IT and find it relatively easy to do so.

Yes and no. The problem is, users don't know we're getting this beta grade stuff until we get it. I'll use videogames as a prime example here. I have previously bought games at launch which have been amazing, I couldn't find a single bug. Other games, I've bought them, they've had a fair few bugs, a day 0 patch and then a second one a few weeks later and it's all fixed. And further games still which come out buggy and stay buggy.

So what choice do I have? Read reviews? According to most reviews games are flawless, I've read a review before where the guy gushed about how amazing game A was, when game A was released and I bought it, it was unplayable with the amount of bugs on it, and I wasn't the only one who thought so (so many forum topics)

So what if I wait? Will that fix things? But then I risk missing out on Game B which is bug free from the start. And how will I know if bugs ahve been fixed yet or not?

I kinda wish there were a "bugged games" website for new releases listing how buggy the games are.

But it's all well and good telling people to "say no to beta quality software" but when we don't know the software is beta quality until we've found that one review that wasn't paid for, or until we've paid for the game ourselves then it really is unavoidable.

0
0

I have some thirty years of coding experience.

Looking at my old code and it calculates 2+2 just fine, but it present the output in binary. The program is totally useless in the modern world. We have learned a lot in the past 30 years and can do much better.

Try comparing something like Zork to a modern adventurer game, the difference is gigantic in the amount of data and code Skyrim or whatever adventurer game deal with, compared to Zork's where you could write down every choice on a small piece of paper.

Our current technology doesn't allow humans to deal with the complexity of modern software development in a way so they can make bug free code within a reasonable budget and time frame.

A simple thing like doubling the number of developers on a project, doesn't mean you get double the amount of code written. We have reached a human complexity bottleneck that no one has yet managed to break through.

8
0
IT Angle

Alternatively

Or we may just have a new generation of coders who just slap their code on top of existing framework, drag and drop their usual functions without a thought for efficiency and have no processes in place to test code performance. I've seen people often rely on new hardware or a move to the latest programming language for their speed increases - and ignoring their bloated code.

Step back a generation and every coder was extremely careful about every single byte. You may only have had 32K to play with which is the size of a big CSS or readme.txt file these days.

7
0
Bronze badge

Re: Alternatively

But the problem is that if every coder was still careful about every single byte we'd not be able to progress. It would be akin to a house builder worrying about how to manufacture bricks, cure wood, forge steel and make glass.

The fact is modern requirements are a lot more complex as expectations have been pushed up over the years.

4
2

Re: Alternatively

CPU cycles are much cheaper than people.

Most software is unremarkable. store a bunch of numbers, show them to user x when he logs on, send out an email, its not some NASA shit they're working on. An engineer might write the code efficiently but a businessman realises it doesn't matter. by the time you've finished writing it efficiently CPUs are already 10 times faster again...

0
3

Software's catching up

Seems to me that this just means that software's finally catching up with the construction industry, where the norm is build it (ignoring any bits of the design that might be inconvenient, difficult, required), wait for the client to notice (and complain), then knock it down and do it nearly right. In the words of Flanders & Deanna, "It all nakes work for the working man to do". Or is that unduly cynical?

2
0
Joke

Re: Software's catching up

In the words of Flanders & Deanna, "It all nakes work for the working man to do". Or is that unduly cynical?

Certainly unduly uncygnical!

(An icon of a swan would be nice, for Swann)

1
0
Anonymous Coward

Funny

Funny to witness this process again and again: There is the CFO being lulled into the false sense of cost cutting nirvana by outsourcing and offshoring software development. How great, these buys cost only a fifth of what these money grabbing developers here want. This Acca trained guy may be the man with the money, but of course has no clue how coding actually works. So, a separate system needs to be set up to ensure that people half way around the world cannot copy intellectual property that was painstakingly developed over years. The code which is then produced is so sloppy and infantile that senior developers need to review, correct and test it. Before they have the time to do the static source code analysis the sales VP is huffing and puffing he needs that code, and he needs it now. Does it do da trick? Good, publish it and ask questions later, dis' a manadshment decishion!

So here we have it: outsourcing that generates more total overhead and costs, bloated business processes that are only 20% effective, code that has knowingly or unknowingly bugs, vulnerabilites and performance issues...the list goes on.

Now, what are product life cycles strategies, long term maintenance and release planning, enterprise archtiecture, granular charging structure....

Anonymouns for obvious reasons.

4
0
Anonymous Coward

I thought it was all "Unit Testing" these days?!

I've been "shopping around" for a totally Free and Open Source alternative to .net, and every language I looked at, every book I've skimmed, every web framework or RIA setup has stressed the importance of Unit Testing, leaving me with the impression that my Cowboy Coding technique was woefully behind the times. Is it?

In my world, the developer has a quick play to see if the code does what it's supposed to, the Support Team meddles with it to see if they're happy (they're the ones who field the support calls from irate users after all) - and when we're all satisfied it's usable, the changes are released.

If bugs are found later, the users are used to it :) .... and it's usally a simple fix with a quick turnaround, so it's never seemed to be a big problem to either party. If a real show-stopper crops up, so long as we can replicate the problem we can usually get a fix to the client in half a day or less.

Given the complexity of software, is that really so bad? In my field it's not life or death, or time critical on the whole, so the really rigorous coding alternative seems to call for so much extra time spent developing, time that could be used more productively adding more features. Paid-for features, billable and bringing in cash :)

1
1
Anonymous Coward

Re: I thought it was all "Unit Testing" these days?!

Unit testing... meaning you have a test for your method, which passes on some inputs. Congratulations! Your method which can take a continuum of inputs passes for one of them!

Unit testing is good. Designing your code to be testable by unit tests means it's more likely to be correct in the first place. But it can absolutely give a false sense of security. You still need proper integration testing.

0
0
Anonymous Coward

Buildings

"It's like complaining a civil engineer doesn't turn up on day 1 and starting to drive piles for a skyscraper. "Hey mate, that looks a bit wonky", "Don;t work we'll sort it out after release"."

A TV programme a few years ago followed the building of a skyscraper. It was interesting how many times there were crises as the building progressed - and quick workround solutions had to be found.

Such problems lie in several areas. New materials, new techniques, new people, and new environments. Even when someone has done something successfully many times - there are always constraints waiting to be unexpectedly breached. Sometimes there are two existing errors cancelling each other out.

2
0
Bronze badge

Re: Buildings

"Sometimes there are two existing errors cancelling each other out."

An Error and an Anti-Error

0
0
Silver badge

Possibility of endless updates

The Internets is wot does it.

The developers got lazy because it's so easy to say "Internet connection required". Then they can push half-baked code out of the door. And if there will be bugs? Oh, we'll just fix them later in updates! Because of the internet connections they can push updates every day if they so inclined.

Using an obligatory car analogy - you get you car now, but the wheels will send by mail later, oh, and about that oil filter - it's not ready yet, just drive around without it for a while...

The users are to blame as well, of course, because they meekly accept this ludicrous model.

0
0
FAIL

Dishonest and Just Plain Wrong

"It does leave me wondering, has software quality gone downhill? " Definitely! I've worked in the infrastructure and support biz for 20 odd years and see a steep decline in software quality control. It's so bad that with some packages, even from big vendors for infrastructure, features and even the install script itself can be Dead On Arrival. It never ceases to amaze me the garbage developers hoist on customers. It's dishonest and just plain wrong. The car analogy is an old one, but still absolutely valid. Would you tolerate a Ford dealer telling you that you have to wait for the MK2 upgrade just to get the stereo to work ? We (customers, sysadmins, buyers, support) are far too tolerant.

2
0
Silver badge

Re: Dishonest and Just Plain Wrong

> It never ceases to amaze me the garbage developers hoist on customers

No, blame the customers for accepting shite at the cheapest possible price every time. If Customer didn't willingly eat garbage then Manager would not willingly sign it off because there'd be Consequences.

Maybe I'm being cynical but maybe people are dumb consumers and maybe I'm not being cynical.

0
0
Anonymous Coward

Re: Dishonest and Just Plain Wrong

Please don't blame us developers... some of us are perfectly well aware that the software is unfit for production, and even risk our jobs to say so before it's shipped anyway.

1
0
Anonymous Coward

It's Agile's fault

It's all about the Agile process. There is no design or time for it so you build as you go make the design decisions you need at the time you need them. With requirements and APIs being constantly negociated it's no wonder that what used to work is now broken and ships as such.

0
4

Re: It's Agile's fault

That is Agile implemented badly.

2
0
PM.
Thumb Up

I recall a HP printer that needed a firmware upgrade straight out of the box , because , well , it didn't print.

0
0
Bronze badge
Thumb Up

Scary?

"The "release early, release often" model appears to have permeated into every level of the IT stack; from the buggy applications to the foundational infrastructure, it appears that it is acceptable to foist beta quality code on your customers as a stable release."

I couldn't agree more, and my experience completely matches yours. The pragma of "release early, release often" is what people say when they actually mean "release early, release broken" but don't dare say it for fear of causing controversy (albeit controversy that badly needs to be caused).

"Just to make things nice and frightening I "like" to, every now and then, search vendor patch and bug databases for terms such as "data corruption", "data loss" and other such cheery things."

Just sign up to a few file system development mailing lists if you want to see scary. Particularly scary in the context of supposedly stable file systems.

0
0
Anonymous Coward

lazy devs? Surprise!

0
3
Anonymous Coward

Re: Lazy devs

Dev's I know who used to write it right are pissed off because they aren't allowed to write it properly these days. The management are just interested in how fast they can get things out the door. The cheaper the dev costs, the more profit. The company can't equate sales with SW quality so in their minds this relationship holds true.

I was recently asked to write some in depth training material for some SW that wasn't written yet. Having worked with the company in question for 25+ years, I thought no problems. Send me the reference spec and I can write the initial take on that then go through and sort out any discrepancies at the end, once the SW is available to test.

Errrrrr reference specs?

Errrrrrrrr Oh we don't do those any more.

I presume MS work this way, I can't think why they'd agree to $1M a day fine from the EU till they handed over the specs for a protocol if it wasn't for the fact that they didn't have the spec of the protocol in question.

1
0
J.T

I recently was visited by a storage company that had yet to have a hard drive failure (good thing too, no online spares and proactive sparing limited to SMART monitoring). Then there are the folks on my team dealing with Oracle ZFS, keeping them under 80% utilized while the system heat and softare raid kills an unusally large number of disks while getting the historically awful Oracle software support.

You get what you pay for.

0
0
Bronze badge

Slow Software Movement?

Oh, f'crissakes no, Martin... InDesign runs slowly enough as it is.

0
0
Bronze badge

And this goes hand-in-hand with what Apple does...

...have their users be Beta Testers for their HARDWARE. Happens all too often these days.

0
0

I'd agree with Paul 87 and therums about the Internet, but I'd like to submit XP as another factor

My reasoning is thus:

Before XP, home and professional markets were completely separate, and their two methodologies as alien to each other as carbon and silicon based life forms.

If you were designing software for NT, then your target market was clearly identified as a networked, business environment, and you designed your software appropriately.

This meant compliance with networking and security standards. Your software had to be resilient and flexible enough to cope with the myriad of network configurations, ACL restrictions, and of course, you are answerable to your multinational client with its army of lawyers.

If you were writing software for the home market, on the other hand, it was much more of a Wild West. Games were dumped in the root of C: so that they could be quickly navigated to in DOS, and rules were merely standing in the way of you gleaning a couple more FPS out of your game.

You were actually rewarded for bypassing standards, blitting the hardware and taking shortcuts.

Along came XP, and these two worlds collided with such force, we are still feeling the chaotic repercussions today. When the NT kernel became the platform for both, XP was flooded with rule breaking games, and hastily banged out code by teenagers in their bedrooms.

This quickly gave rise to the situation we are all familiar with. You had to run as nothing less than admin for all your software to work. This quickly bore a vicious circle, with small developers, lacking the resources to fully research all the intricacies of the NT platform, simply making assumptions that this should be the norm.

As evidence I submit my time as sysadmin in a school, 5 years on from XP release. The niche software, sometimes written by programming teams of one, would make a security consultant break down in tears, often storing config files in the windows folder, ignoring the registry, making assumptions about profile folder rights…. I could go on… and on…

Even Mozilla are guilty of many similar faux pas, which is why you don’t see any real corporate take-up. The sudden influx of lazy and/or hacker coders gave birth to a compromised NT environment that lasted more than a decade, giving rise to an entire new generation of coder who believed that this was the way things should be done.

I’ve only recently seen a change in trends with the proliferation of Win7. If the UAC comes up at any time you’re not installing NEW software, the programmer has done it wrong. End of story. The UAC is embarrassing a lot of corporations to go back and write it the right way, but we’ve still a long way to go.

Perhaps Win8s Android-esque declaration of rights at install time will push things further in the right direction?

0
0

Software Quality? Who cares?

First, let me state that, obviously, software should be of good quality. As an infrastructure person you should expect that. But let's be honest, who else cares about that?

The developers can try to do their best to make sure it works, but they don't have access to you incredibly complex production environment. Besides, they won't get any penalties because your environment can't handle their software anyway. You might tell a doctor what other medicines you're taking before they give you new (fully tested) medicine, but you won't tell the developer what other software you use.

The buyers (aka your boss) don't care if the software is good either; they just want it to be installed into your environment and to be able to work with them. Oh, will it crash your other applications? Doesn't matter to them. Oh, could you also support my new new shiny Somephone 5 as well?

Neither the buyers nor the sellers thinks the quality is important. If you want to change that, you could start by telling them. :)

0
0
Silver badge

Why bother to make it better

Since SW makers have convinced themselves and seemingly the world, that normal laws don't apply to them, why should they bother to make it any better. You "agree" to a license that says the only right you have is the right to hand over your money on their demand.

Until they are forced to accept that they are responsible for failures in the products they expect to be paid for (an act normally referred to as selling) why the F*&^ should they worry if its sh*t it won't cost them anything.

0
0
Thumb Down

So when will Software Development become Engineering?

I think (and have for a long time) that Software Development is stuck about where Brunel was with Civil Engineering.

We can see the possibilities, but we haven't yet worked out the best way to do stuff and so everyone reinvents everything each time.

Back in 18xx Civil Engineering was exciting because people didn't know how to build large strong bridges and so did the best they could. Then, when the bridge fell down in a storm (Tay Bridge, or Tacoma Narrows more recently) they did it better the next time.

Nowadays Civil Engineering has progressed to the boring position where we can build something like the Padma bridge - any consulting civil engineer could tell you how (or give you a max of 2 choices) and the actual construction gets farmed out to one of several global consortia.

We're still at the 'Bridge falling down' stage; but frustratingly seem unable to learn any lessons or improve matters the next time and probably won't until some real disaster strikes and the losses from cr*p software equal the casualties from earlier 'real' disasters.

1
0

Re: So when will Software Development become Engineering?

im not in a hurry for it to change

You said it yourself, the work will be farmed out to global consortia who will employ a limited number of the world's best engineers and an army of grunts. They probably won't employ you or your friends and if they do the work will not be fun as you will apply x formula to y problem or get fired. With emphasis on the firings and shitty treatment, as no one really cares how good an engineer is anyway.

0
0

Page:

This topic is closed for new posts.