In the old days (and still today) lots of "sysadmins" were programmers. Mostly because programmers were the only people that used computers and then some of th

In the old days (and still today) lots of "sysadmins" were programmers. Mostly because programmers were the only people that used computers and then some of them happened to administrate those. That's at least my recollection from an academic/university setting. The ones I ran into were awesome programmers. IMO "software reliability" shouldn't and can't be thought of as its own feature. Reliability is part of parcel of every feature. You can't make bad software reliable and good software doesn't need the "reliability" tacked on. This mindset (similar to thinking of "quality" as an add-on from the "QA team") seems very problematic to me. At the very least it's an unnatural way of getting there, at worst it just doesn't work. Where I would draw the line though is the reliability of the infrastructure, that's not the domain of the software developer, so it's totally OK to delegate that portion and draw a contract (e.g. in your item #3).