

Let’s write better software - knasteddy
http://blog.filipekberg.se/2012/09/27/lets-write-better-software/

======
davidw
> What’s your suggestion on ensuring that we deliver high quality?

Understand the economics behind software development, and stay as close to the
edge of cost/quality curve as possible.

Simply wringing your hands about "doing better" doesn't do much. You have to
understand why 'cheap / not so good' wins in some cases.

------
abraxasz
> We’ve seen that consumers are not scared of changing their behavior, as
> that’s what we do; we adapt. Vendors need to start delivering better
> software and hardware!

Uhm. This is a rather bold claim that certainly needs some kind of reference
or proof. In my experience, this is quite the opposite, and people tend to be
pretty loyal to electronic brands. I'm not saying that people never switch
brands, but that they usually won't do it unless the alternative is
significantly better.

Why is that so? Because when you're used to a certain technology, there's
almost always a cost associated to change: time to setup a new workflow,
getting used to a new ecosystem, incompatibility, or just plain time and
hassle.

I'm taking my own case: I'm currently running Lion on my Mac, and I'm sure as
hell not going to update anytime soon, regardless of wether Mountain Lion is a
better OS. Why? Because I've a pretty complex setup (multiple programming
environment, multiple libraries that require special installs and special
versions, etc..), and I know that it would take me at least a month to
completely transition (that is to catch all the incompatibilities, etc..). Why
would I waste a month of productivity when my current setup works well?

Anyway, my point is that the claim: "consumers are not scared to change their
behavior" needs some backing up, because it isn't obvious to me.

------
zwieback
"As consumers have somewhat adapted to this and expect rapid updates for
software’s. The vendors no longer need to spend as much time on finding bugs
as they did before."

This problem is as old as software itself. At this point I believe that it
will never be addresses since software "can always be fixed later" and the low
barrier to entry encourages this behavior.

