Source control should be your single source of change, and check-ins should cause a chain of events via continuous integration and issue tracking. A checkin should cause a build to kick off if it is successful it should deploy to an integration environment where tests should smoke test it. If it smoke tests it continuous integration should up merge to a test branch, deploy to test and then update the ticket system to update all associated tickets to ready for test. When the tester verify the tickets automation should again up merge to release and automation should release to production on a release schedule. This is a solved problem.

Except for all the costs of maintenance. It always costs more, generally in the way of time.

> With virtualization and continuous integration the cost of doing it correctly is marginal

Until you have to debug while the integration fails.

> This is a solved problem.

Even with unlimited funds, you get a cost of time and communication. There are tickets and tickets and a queue and a release schedule. The optimal path is not as simplistic as you would fantasize.

I'm guessing this is relating to my SQL mishap in the opening lines? You're making assumptions that I was doing something manually in production here, and not that I was executing a script that was buggy or against the wrong machine.

Sure, we could build safeguards against this, but it wasn't something we really considered would happen. Needless to say, we've learned from that one!

As others have said, software is a young field, and in many ways we're still pushing and exploring the boundaries of what's possible with software. All of us are still very much "early adopters" in this nascent technology experiment / revolution. The nature of demand and untapped potential for software systems creates a financial incentive for high-stakes rapid experimentation at the expense of sloppiness (in attitude and in software quality) we've seen for as long as there's been software.

I do think investing a little bit more time up front and using TDD combined with good leadership / experience is ultimately healthy for your product and team, if you can manage it. However, we shouldn't forget that being "cowboys" got us to where we are today, and continue to break open exciting new opportunities for software.

There are static analysis tools that can identify such problems ... sometimes ... maybe ... depending on the language and frameworks in use. But to deploy such tools you have to know about them to begin with. And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.

Unfortunately, knowhow can't be automated away entirely just yet.

Analysis tools are the wrong approach - that code should be simply impossible if you're typing things correctly, and inadequately typed code should be very obvious in code review.

> And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.

Most devs could write such a thing if the company told them to. The reason "that's not what they're being paid to do" comes down to process.

Most organizations barely have enough of a budget to implement the applications they actually need using already existing infrastructure (frameworks, tools, etc.). Asking these organizations to roll their own infrastructure is like asking ordinary people to run their own water or power utility.

I don't understand this dichotomy. What kind of engineer designs anything for a third party without gathering their requirements?

http://www.fastcompany.com/28121/they-write-right-stuff

That is unlikely. For computational complexity theory reasons, writing correct software is extremely computationally expensive (regardless of whether or not the language is Turing complete). In fact, it is "the hardest problem in computer science", in the sense that any problem with bounded complexity can be efficiently reduced to software verification. Even verifying finite-state-machines (the simplest computational model) is PSPACE-hard.

What we can do is find many ad hoc ways, each helping to some extent with some kinds of correctness properties.

NASA with the Space Shuttle software came pretty close. http://history.nasa.gov/computers/Ch4-5.html

But enough money and the goal of making it infinitely flexible, having all the possible features, or the most perfect UX that a team can not decide on what it is will only make the software more bloated than it's reasonable, and fill it with bugs.

Of course, making mistakes is only human, but mistakes should never get past the build process (compilation, automated testing). Any mistake that does reflects an error in your design (not making your code amenable to verification) and/or your process (not capturing requirements in tests).

According to empirical studies, practicing TDD leads to a 90% (yes, that number is correct) post-ship bug reduction at an upfront cost of 15-35% more development time.

Which seems like a pretty good tradeoff, to me. (And I've experienced it firsthand.)

http://research.microsoft.com/en-us/groups/ese/nagappan_tdd....

Also discussed in this infoq article

http://www.infoq.com/news/2009/03/TDD-Improves-Quality

Here's someone's thesis paper on it, with data:

http://www.nomachetejuggling.com/files/tdd_thesis.pdf

There's also interesting discussions like this

http://programmers.stackexchange.com/questions/206355/the-re...

"it is my experience that the value proposition for TDD grows exponentially as the time and resources involved in a project grows linearly."

This has also been my own experience.

This person's comment also is interesting and has data

http://programmers.stackexchange.com/a/210756

Some of the above is empirical (read: scientific, no-bullshit) data.

My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming." Lacking any unit tests whatsoever (TDD or otherwise) should be called, "taking stupid, extremely hazardous risks to save a little time, like reading your phone while driving"

I've not found a programming task in at least 5 years that wasn't waaaay better-written when done via TDD. Some things, like IO, can be a challenge to unit-test, but that's why we have great ideas to solve that like Gary Bernhardt's awesome "Boundaries" talk https://www.youtube.com/watch?v=yTkzNHF6rMs

Yes. It's pretty easy to write provably correct software, just expensive.

> Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring

Not my experience, but even if so, if you require your software to be proven correct then it won't matter - any refactor that breaks it simply won't be accepted.

> More money also makes people design lazy, so that instead of finding clever ways to reduce effort and improve uniformity, you just have everyone make their own forms.

Um what? What does this have to do with anything?

There are lots of good reasons to refactor - if indeed frivolous refactoring is more prevalent I would think this kind of opinion should be supported by a source/reference.

As another example, when I was logged in to my mutual fund web site, I found a button that says Get Statement. Since I wanted to download one, I clicked it, and it said, "Your statement will arrive in the post soon." They sent a paper statement without confirming me what I wanted. When it arrived, I threw it away, of course.

In many cases, poorly built software increases costs for the company as well, so financial incentives are only part of the story. Incompetence is another part, maybe a bigger one.

If you ship something that loses data and you have to start restoring backups and patching data, it probably would've been cheaper to do a little extra testing.

Like everything; it's a tradeoff. I think we're universally bad at playing the game!

It may sound silly to some but I'm really interested in what people think about this.

Have you tried hiring a programmer lately? It is very hard, there is a huge demand and most programmers I know receive several offers a month. The demand for software is CRAZY. So we all do what we can: quick and dirty when it is good enough. Just like in a country with no roads, any dirt road and crappy pavement is better than nothing if you have hundreds of trucks that need to go through RIGHT NOW.

So here it is, websites are made hastily, tech half work, but are better than nothing. How much of the things you screencaped have more than 5 years of existence? Like you said, we are software developers. We write software and we write bugs. Right now, there is far more need to implement new features than to correct bugs. Hopefully it will change at one point but right now this is the crazy race forward, and that is a good thing!

:'|

Could you take a look at how they're receiving offers and perhaps put some suggestions together on how to duplicate that effect? Most programmers I know have had extreme difficulty getting a job, especially one that would pay at-or-above the average rate (per Glassdoor).

Are candidates with copious open source contributions getting hired primarily because of those contributions, or at the very least being spared the indignity of the white board and trivia questions during interviews? In my experience, no. Interviewers generally don't care, or perhaps their process is too rigid to admit the deviation that caring would require. In fact, when pressed, many will even admit outright that they don't care, claiming (as I've seen here on HN) that they have no way of knowing for certain that you're the true author of your purported contributions or that your contributions alone can't really demonstrate how you write code (like a white board presumably can).

The only reason they value open source contributions is that it amounts to free labor, and it demonstrates "passion"--a quality that they associate with susceptibility to exploitation.

If you contribute to open source, your name and work are out there. People can find out about you and see some of your work.

There are other ways than contributing to open source too. For example, I've got a number of offers because I run a local programming language meetup.

Basically anything that puts your name out there will help get offers. If nobody knows you exist, they can't offer you jobs. That, I think, is where open source can help a lot.

Some of that may depend on company size, but in my experience (mostly small startups) it has been a huge benefit.

And besides, that is very specific to web jobs. There's an awful lot more to the industry besides.

I can assure you that the bar for entry into my field is much higher than software. Like medicine and law, engineering requirements are strictly set by state law and professional boards. You need at minimum a bachelors in engineering to get a foot in the door. There is no self studying or civil engineering bootcamps. Afterwards, you need to become an engineer in training (EIT) by taking an entrance exam. Four years of experience later, you can sit for your professional engineers exam to become a licensed PE.

So now you're 8 years down the hole, finally licensed and ready to actually practice in a professional role. The kicker is that you're still probably making less than a fresh CS bachelors student working at <foo> corp in a tech hub.

I'll stick to posting on Reddit and contributing to projects.

There is no such trust in the education of software developers, perhaps because software development is such a new field. I've worked with great ones without a formal education and terrible ones that graduated from good schools. The way to 'prove' yourself to someone when they can't work with you (e.g. first stages of a hiring process) is to demonstrate your work by using technical articles, GitHub commits etc. Also, that stuff is not specific to web devs, I'm sure you can find every kind of project under the sun on GitHub.

Photographers, graphic designers and musicians.

EDIT: and, come to think of it, don't musicians need to practice for a long time before even getting a chance to perform for pay?

Programming is similar. You hear the stories about how some tech founders focused their energy on programming, it took off and they dropped out of wherever.

I'd argue that for every one of those, there are scores of people who do it just for fun like they did, get nowhere but do it anyway because they like it. Just like there are scores of guitarists for your Clapton, Hendrix, etc.

Open source contributions to me look a lot like people, for the most part, enjoying themselves and getting better at a hobby.

It perhaps depends on the specifics of the jobs you go for. For example, if you're a musician producing audio for eg film, then you definitely are expected to have a portfolio, but if you go out and play for an audience, then you probably don't.

Doctors have conferences, Chefs have "Chopped", and those are only the "mainstream" ways the general public knows about. Most others you mentioned have industry/trade magazines for example.

I suspect the other professions would benefit as well, it probably simply hasn't occurred to them yet. It reminds me of when I was watching a bodybuilding competition in the 80's and thought the posers could really use some advice from a professional dancer. Sure enough, this occurred to one of them, they did a routine that blew away the others, and then the rest of them did.

If not, then can you share some tips on how to concisely include a job applicant's open-source contributions in their resume?

Also that is what your github account is for.

There is no stronger signal that you're a good developer than already having a job at a company that has stringent hiring standards.

I get multiple serious recruiter contacts a week. Mostly via Linkedin, but also via direct email for the enterprising recruiters. All from companies most people would kill to work for. I even get linked-in email from linkedin recruiters.

I ignore most of them. They know it's part of the game. One day in the future I may need them, and there's no point in pissing them off - they're only doing what they can. You gotta have a huge funnel to hire even 1 person (it's probably 1000:1 for contacts/hire)

I can understand that if you are starting fresh you won't be able to be already employed by a well known company. However you have to start somewhere and it's important that you get some experience in the field you want to work in. Obviously this depends on the job you are applying for whether it's a junior or senior position etc.

I think it's important that you don't have big gaps in your CV and can show or present strong social/soft skills. One of the most important things for me is to be honest. Be absolutely honest about what you can do and not. Don't flood your profile with all the latest buzzwords and technologies if you never worked with these before. This might attract couple recruiters but it will be most likely the black sheep amoung them.

Be serious, honest, friendly, open minded and just yourself. :)

But of course, I'd only ever heard of linkedin as "the" professional networking site - I didn't even realize they had competition!

People are just people no matter what role they have in that moment and most people are susceptible to be impressed by superficial things (like your current company name).

Also most interviewers failed the interviews I was in... :)

2. What technologies do they specialize in? I see lots of job posts for Rails and React and relatively few for COBOL. I see a lot of jobs for Java, but a higher percentage of those are of the lower paying variety. This is likely location dependent and is a bit of a catch-22.

3. Are they any good, but perhaps more importantly, are they able to demonstrate that they're any good in an interview setting? There are a fair number of truly bad programmers out there. There's also a fair number of programmers who may be good but are unable to demonstrate that in an interview. Interviewing is hard to get right -- everyone has their own take on it, and it's rarely backed up back actual data.

The people you see getting tons of offers probably have the right combination of location, resume, and interview ability. If I had to pick the single most important factor in getting a lot of offers, it's location. If you are in an area with limited tech jobs, the number of offers you can get is obviously going to be limited as well.

Getting a career at all without a CS degree required moving away..

Sure, I get lots of recruiter emails, but almost all of them are sent identically to 100 other people as well.

Most emails I get come from external recruitment firms, only sometimes does someone at a company reach out to me directly. But even then it's only an invitation to apply, it doesn't mean I'm actually especially likely to get the job.

(I also get about 1-2 recruiter spams a week and occasionally one that seems genuinely tailored to me specifically. This might be what the OP was calling "offers".)

As others have mentioned, it's social proof.

Most of the inquiries I know of (for myself and others) are generic recruiter spam, or word of mouth referrals by people looking for really cheap work. So yeah, there's lots of work out there to be done, but much of it is in far less than ideal situations.

I do receive several "inquiries" per week, mostly due the fact of having left my CV (obviously now very outdated) in many job sites when I was looking for a job in London, almost 10 years ago.

They are of the type "Dear [Name], I hope you are well. Would this role be of interest for you in your current situation ? [role description]. If not, do you know some friend of yours that would ? Best regards, [name of person totally unknown to me]."

This is not even a serious inquiry, much less an "offer".

People who focus on solely ASP.Net without an understanding of the underlying tech will have a harder time finding a job than someone who knows several language and understands how a computer works.

the interviewer proceeded to ask me a deluge of very specific questions about said language, including implementation details of the language itself! all of the questions could have been looked up by an intelligent person online within minutes. and this was a well established, small, but well known company.

all of my software interviews can be summed up with two words: algorithm questions. but yet, my skills lie in architecture, writing bug free code, general design skills, testing, UI dev and client feedback, etc. none of these skills have never had the chance to be discussed in an interview. i came from another field and haven't spent a lot of time in the algorithm space. i can work through them as needed in interviews just as i do in a job, but that is rarely cared about in interviews. people want binary answers.

To my knowledge there is no proven way of finding out how talented one is except working with them for a while.

The best way to gauge ones skill level, IMO, is to observe how their code survives contact with the end user for a couple of years.

[1]: https://en.wikipedia.org/wiki/Pareto_principle In case you didn't know this but srs you're on hn

a) do something interesting

b) do good/high-quality work

c) be excellently paid

- pick two. Unsurprisingly, most people choose high-paying jobs that sound interesting, resulting in shitty bloatware from hell. Of course, many programmers don't even get to choose at all, they can call themselves lucky if their job has one of these benefits.

You mean recruiter spam? That's not a job offer. At best it's a liberally-dispensed invitation to submit yourself to some company's drawn-out, degrading, and ultimately capricious interview process.

The "huge demand" is for 20-somethings who graduated from top schools who are "passionate" and can be over-worked and under-paid.

Even a major revolution in database tech would maybe reduce costs, downtime, or latency by 10% or so, max. Since that sort of expense is never the dominant factor in a company's success, it will never be worth serious commercial investment. And as far as academia goes, there is research happening, it's just a slog because all the low hanging fruit has been picked and now people are just optimizing. Fields always slow down after the good stuff is discovered.

IMO AI is the only pure CS field worth studying right now, that tree has barely been touched at all. The mundane stuff like OS, databases, and languages have been studied to death, and unless an Einstein comes along, there's not going to be any serious motion unless the AI nut gets cracked first.

Here's what it reminds me of: "jungle capitalism".

Back in 90s one could easily land a job or a subcontract if one is capable to do so. I used to be UNIX system administrator and Informix DBA, and there were literally tons of requests for complex database server setups and performance tuning even in such shithole like Russia. That was the market.

Nowadays, except for bunch of valley startups and megacorps, which routinely select top graduates from the ivy league universities (as we have seen in now famous salary disclosure posts), there is no real demand for programming. There is no demand for high-quality components or specialized solutions outside established insanely beurocratized packer's ecosystems, such as Java EE, MS, etc, which allows middle-aged mediocrity to get its salary.

Suppose you are a freelance programmer, who has that golden classic CS education (algorithms, data structures, programming languages). Is there any offers beside Jomla theming or JS or occasionally Android coding? Nope. All remaining software engineering action is inside startups or megacorps, and even it is usually nothing but piling up layers upon layers of Java (or nowadays Node) crap, which can't even be polit-cortectly called "over-engineered", because it is simply arrogantly-stupid.

The mantra "write your own Nginx first" does not work either. Igor had a nice sysadmin's job in an oil company so he was able to spend couple of years for prototyping and slow knowledge-based engineering, as opposed to fast and "productive" copy-pasting in an IDE.

If there is a real demand, there must be the market for it. Have you seen any demand for good stuff (Erlang, Haskell, CL, Golang, kernel-quality C)? Me neither. What we see is mere evolution of valley's sweatshops for top graduates we call startups.

To answer your question with a question of my own: If you think that software/service X sucks, why not see this as an opportunity to do something about it? If X really does suck, and if the reason X sucks is because it's being designed/managed all wrong, you could make a ton of money for yourself by building a company around building a better X which doesn't suck. Build an alternative that prioritizes reliability over agile/fast-releases/new-feature-rollout, or whatever you think the problem is.

If you're right, if users genuinely care so much about reliability, if reliability is important enough to sacrifice feature-experimentation, time-to-market and development-costs, then you should be able to achieve great market success and win over the current unreliable dinosaurs. More generally, some other company/startup that espouses the above reliability-centered philosophy should be able to enter the market and start dominating it.

The fact that neither you, nor anyone else, has killed off the companies/services/products that you're complaining about, leads me to suspect that users in general are willing to give up some reliability, in exchange for other benefits like low price and novel features. I know I certainly do.

Blaming users is part of the problem. Yes, they vote with their wallet, but their vote is usually made in ignorance and is often mislead by companies that are so used to dissembling and exaggerating they call such antisocial behavior "best practice".

That said, it is true that this is largely a problem with the economic incentives. Capitalism optimizes for businesses that are financially efficient, so the business that sells the lowest quality product they can get away with is "successful". This becomes even worse in software, where quality is harder to see directly. Even the people that write software can have a hard time evaluating "quality".

The solution for this situation is simple, but it's basically taboo to talk about it: liability. If you sell software, you need to be liable for any damage it causes when "used normally". For a decent sketch of how this might look, see Dan Geer's explanation[1]. There may be other ways to implement liability. I suggest that the software industry should find a way to implement this as soon as possible, if they want any say in what "liability" means.

Yes, this will raise development costs; spending more for better development practices was the goal.

[1] https://www.youtube.com/watch?v=nT-TGvYOBpI#t=1531

Even sites who clearly deliver malware through their ad network don't get sued.

Liability towards one customer is also not the same as liability towards thousands, or even millions of users.

I have to agree wholeheartedly with this statement. I'm relying on software to basically help me run my life. Thanks to software, I can accomplish more than I would otherwise. (OTOH, I also take on more, which is a whole other post on making ourselves crazy by trying to do too much.)

Still, there is room for improvement. The problem is that no single point of failure exists. It's a layered problem involving economic incentive, unskilled people jumping into development to shore up the shortage of labor, an immature consumer base, a dizzying array of tools, methodologies, and standards for developing software, etc.

At present, I don't see any way out of the dilemma.

A lot of the examples in the blog post are about sucky corporate websites. You aren't going to set up a competitor to IKEA, let alone an electricity company, because the quality of their IT is poor. That argument works in only one case:

• The product is pure software

• It doesn't have any barriers to entry

• The quality of the incumbent is so dire, and the chances of improvement so low, that it makes sense to replicate their entire product investment just to "do it right this time"

Unfortunately such opportunities are rare.

I think there are some tragedy of the commons situations though, where everybody is relying on extremely underfunded common infrastructure. It was only after a bunch of expensive security holes that the users of this software started to pay more attention:

https://www.coreinfrastructure.org/

But there is plenty of other stuff that needs to be done, that would benefit everybody, and doesn't involve security holes.

I try very much. I try to report any issues I find like this (I spoke to 5 different people at NPower trying to explain their issue, and nobody cared or understood).

I have a job/family/life. There's only so much time I'm prepared to put into trying to make silly things like these better, and I'm certainly doing far more than most! :)

I had already several very hard and harsh fights with my bosses, even with the CEO telling them "everyone is not very good at this company" because I care about quality very much and rather fight over it than sit quietly and just produce shit.

I gave "talks" about specific topics, constantly grab the opportunity when I can tell them about a new concept, Clean Code, better tools, whatever. I introduced TDD, CI, automatic deployments, will introduce CD next month over a year I have been working at my current company.

If you are one of the better developers you can and should fight against lazyness and low quality, even teach the ones who cares/know less.

Also it's very comfortable to blame your boss, but you can do very much about this. I introduced automated testing not because they asked me for it, but because I thought is important. I educated them that this way, development will take a bit longer, but will be higher quality. You can even do things which improves quality and they don't even know about. My next step is to introduce third party services (which they never used before and always went with the open source or cheap solutions) which makes our work easier, so we can focus on what's important, and make it better.

This can be thought of as a type of error correction. If you don't fix problems as they rise up the chain of command, those problems eventually become policy.

http://ogun.stanford.edu/~bnayfeh/plan.html

(mild language warning, of the form "____ happens")

Much like the OP, I spend a great deal of time trying to guide my clients to work in ways that guarantee better quality. The mantra in a lot of these places though is 'Features first, feature bug fixes second, other improvements never'. Without the folks delivering the software (Everyone from QC, DBA's, DevOps Engineers/Ops and Developers) pointing out the inherent danger in this nothing is going to change.

We're still far from perfect, but I we're definitely on the right track. It's possibly because we try so hard to improve that I get so frustrated when big companies appear not to :(

I don't have that many people around me that are worth influencing directly, so here is the way that I do it :

1) I divide up the TODO list and customer requirements into the 'Little Things' and the 'Big Things'.

2) Customers / Managers / Users seem to love the 'Little Things', and feel like they are getting great value for their dollar when so many of the 'Little Things' can be delivered in a relatively short time, it looks like great progress to them.

3) I always do the 'Little Things' at the Customer's site, in the Customer's presence. I always do them during the day, and I get the managers involved as much as possible. Be a good corporate citizen, and get paid on time.

4) Doing lots of little things on an hourly rate is a good way to generate cash quickly, and get paid on time. Its useless in the grand scheme of things in terms of software development, but it is needed to keep everyone happy and ensure that you can pay the bills on time. As you can see, this is all about cash, fast cash, and smiles and happy customers all around. It can be borderline degrading at times, but there you go. Milestones and Invoices and Smiles, and more Smiles and Cash.

5) I don't even bother trying to explain the 'Big Things' to these same Customers / Managers / Users, because it just plain scares them. They will never believe that software can ever be that complicated or difficult. It really scares them in fact. They want their world to be manageable, understandable, easy to estimate, easy to achieve ... that want to feel like they are 100% on top of things and in control. So I just don't talk about the 'Big Things' at all. Peering into the void that is the Big Things is the quickest way to make a Happy Customer (who pays on time at a good rate), into a very upset individual.

6) Bank the money and take time off. Turn off the phone, close the email app, stock up the fridge, tell people you will be out of town for a while. Get comfortable .... and code. Code the big things. Do it in the comfort of your own setup, away from everyone, and take your time. No deadlines, no clocks, no timesheets .... just you, an editor, a github account, some emergent ideas that may or may not be well defined, and some code.

Working on the 'Big Things' is simply not negotiable.

I never charge for doing the 'Big Things', and I never discuss this with customers, or try and use it as leverage in future billing arrangements.

Working on the 'Big Things' is simply not negotiable.

Working on the 'Big Things' is why I program and why I ever started to get into this in the first place. Being able to properly immerse myself in the Big Things, on my own terms, on my own time, out of my own pocket ... is compensation enough, and worth far more to me than any paycheck ever will be.

Working on the 'Big Things' is simply not negotiable.

Having a set of 'Big Things' in my toolbox then enables me to re-enter polite society for a while, in order to crank out some more 'Little Things' easily and cleanly, and get the bills covered. You need happy customers for that. Happy customers with Milestones and Ticks in Boxes and Smiles and Invoices and Cash on Time.

But working on the 'Big Things' is simply not negotiable.

AD login was written down, missing the last character that was there before, tried as it was, finally tried with the missing character, still no go... three calls to cusomer support later, disconnect ethernet, and able to login with secure wifi.

Able to login, setup a couple things... hmmm, no access... Told my email address was now a different one, ask about original email address. No bueno... wait a day, call back (still waiting on response from original issue), decide I can't wait, needed to get in. No email access, no lync.

Finally get a call from email support the next day (weds), but it's 7:30pm and I'm out to dinner, didn't recognize the number, sent to vmail... the issue was that I had no email, the message on the voicemail said "email me", no callback number, no email address, how the hell was I supposed to email them.

Two days later, I come in, I'm able to send mail, but not receive... there were somehow two email addresses configured. After the weekend, I'm finally able to send and receive, but now have a 3rd email address, and have to manually fix my profile in a bunch of internal services that were auto-populated at first login. Not to mention a VP in another division (with the same name) getting a bunch of email meant for me, because my email was fubar'd.

It isn't just software, it's entire processes. I basically sat for a week, twiddling my thumbs (mostly), because I couldn't communicate... still waiting on access to our ticket tracking system (was told to wait until I had email and lync).

I'd cry if it weren't so funny.

Most over heard arguments before standing up: hey, we don't have a choice, there are all these companies competing with us doing the same. The other arguments for not caring about quality is : not having customers because you are a startup and that well, we will all be wealthy after we will have sold our shares and you will be able to care with the next management.

Bosses get what they ask and pay for.

> Organizations are ambiguous, often intentionally, about the relationship between > production targets, efficient use of resources, economy and costs of operations, and > acceptable risks of low and high consequence accidents. All ambiguity is resolved by > actions of practitioners at the sharp end of the system. After an accident, practitioner > actions may be regarded as ‘errors’ or ‘violations’ but these evaluations are heavily > biased by hindsight and ignore the other driving forces, especially production pressure.

I can't. Nowadays so much jobs are regulated per diploma/certifications that it is hard beginning again and regain while "older" the momentum for credibility.

The funny part I see breadmakers, cooks, construction is also suffering the same problem. I am currently in France, restaurants for average people are so bad, they do stuff that intoxicate people. I can do bread, cooking, fixing bikes and I do better than "pro" nowadays" without a diploma in their field.

Something systemic seems to be going on. Like people are just taught to execute and required to obey, and bosses don't know the craft of the people they should lead.

Basically being a boss boils down to the capital you can have, and competition seems rigged in favour of people being born wealthy.

I don't think that birth merit outweight a sane competition.

I find the Figaro monolog that inspired French and US revolution about the old monarchic regimes to be very actual.

Weirdly enough author's right says it should be in public domain, but it is impossible to find a link to this essay that is very actual.

I think that it has always fueled my intuition that a profession should be defined by the craftsmanship and not he education.

But my "clear conscience" doesn't help the overall situation.

How can we make the industry as a whole less bullshit? That's the question that I want answered.

And I found asking questions a better way to make people aware.

People will first deny we all have shit in the eyes. And say you are exaggerating.

But, ask them about their experience in IT, but also every days inconvenience because of loss of quality in product. There is a pattern. People feels like industry don't care anymore about consumers. And let them tell their part.

It makes people realize they miss the simple boring life that works.

And maybe they saw something you don't see and they can help you and you can help them.

My first way to improve this is to help people be better consumer by sharing simple way to spend less and get better products by focusing on rational choices. I also sometimes learn. I also sometime am bullshited.

But, you know: trust but check.

On the contrary, it's an acceptable excuse in lots of situations. The finding at Nuremberg was that there is a line beyond which it stops being acceptable, and murder is on the far side of that line. But most things in commerce are on the near side of it.

In other words, a moral obligation to give up your job rather than tolerate sloppiness, applies when you're dealing with safety-critical stuff such that sloppiness could get someone killed. It doesn't apply when the sloppiness will cause minor inconvenience.

I think generally all these problems are indicative of several factors combined. Laziness, general lack of attention to detail and pure developer incompetence, general need to push out stuff too fast (marketing decisions policies) and then finally complexities in the software systems itself. Today any given software system is enormously complicated to a degree that nobody really understands the systems completely. In fact it's a more or less a miracle that things work as much as they do considering all the billions of bits that need to be just right for me to even write this comment. That being said, I don't think there are shortcuts here. Better quality can be achieved but it requires the mindset for doing things that way. And it's going to require testing. And a lot of it, unit tests, regression tests, automated test suites.

Personally I find that when I write code I often need more unit testing code than the actual code to cover the system under test functionality properly. I'm talking about a ratio of up to 5 lines of testing code to a 1 line of real code. Sometimes I can get close to 2:1 or 3:1 if the function/class/method is not very complicated. Anyway even if you now take that conservative ratio of 2:1 and go look at any random open source project I'd be surprised if you would actually find that much testing code there. Good luck.

That developers insist on using unsafe languages like Javascript speaks volumes.

They don't. AFAIK, lines of code is the only known metric with significant correlation with bugs so far. And if you ever wrote anything in a good dynamically typed language, like Perl, you know that its type system never causes any problems.

Some of those are clearly complicated issues but there's so many cases of just plain laziness it's infuriating. However, I don't blame the developers entirely. There's so much pressure from management, product managers, etc. and so much cost cutting it's ridiculous. It doesn't directly affect the bottom-line though so I'm not sure we can do much except expect more from ourselves and get used to it.

This is not just a failure of the software industry, you see this in every field where there's hardly any feedback from end-users to the vendor.

Look at the first example. An escaping bug. When did you last see an escaping bug in a desktop app? The shift from Visual Basic/Delphi/C++ Win32 apps in the 1990's to the web introduced this category of bug that was previously rather rare.

That sort of thing isn't really caused by lazyness. It's caused by our tools creating holes for us to fall in to, and then developers falling into them.

I think in general though, we would be better moving slightly towards the "spend a little bit longer" end of the spectrum.

Most of these issues seem to be management decisions.

Like giving a car mechanic a few cheesegraters and a dog, sticking him in an open field in a thunderstorm, and asking him to rebuild your engine.

He could be a prodigy. But there's water in it, man. There's bloody water in it.

Half of the stuff on that page should not involve any programming at all. The nPower one, for example. Yeah, it's broken, but that's not the actual problem. The problem is that it would take about 5 years to report the issue, so no-one knows it's broken. Just give an email address or a telephone number, and actually employ customer support instead of paying yourself $50M/second. Done.

For example, take the podomatic example - that's just a sloppy function written by a dev. The NPower thing is just sloppy setup of the website and bad links in email templates. The MS thing, well why did the devs add jQuery to a site that is so incredibly static?

Devs make a lot of decisions that influence the quality of software and I think we need to start taking more responsibility for that.

Separate event chains from your UI so much as practical, and avoid classes that look like Car, Wheel, etc that are too smart for their own good.

I've seen people blame developers for, like, female characters in games being oversexed. Newsflash- that's a business, product, and design decision. People even tried to blame engineers for the VW emissions scandal! Companies nowadays set ridiculous release schedules, overwork their developers, and release crap. But sure, blame the devs, that will probably help.

The author here is a dev so there's really no excuse.

How do you know?

I agree with your point about taking more time to think about the way your code works, to design data structures, to use rigorous methods to make sure the code works, but ultimately you still have to check things. If you haven't automated those checks then either you're checking things manually or you're not checking them. On any significant project there's too much code to check manually.

People take % of code coverage as some insurance and spend time writing stupid tests instead of writing robust code.

People also don't think that unit tests are constant maintenance burden and a time waster - you change this and that and then you need to spend time entertaining the tests.

Again, use your brain, not your fingers - it's that easy! Oh, and don't program using a dynamic language saving keystrokes, but wasting, even more, writing brainless unit tests!

At least in my personal career, most, though, and real issues come from race conditions. But I've been fortunate to catch them quickly by using my brain. And that's what we lack today - developers who use their brains, who don't spend too much time on emoji reactions in Slack and finding the right GIF.

There's plenty lots of code monkeys and code gluers today that can't even implement a bubble sort without googling it!

That's why you test interfaces, that you've spent time designing so they don't change often. You, or someone else who isn't as good as you, can change the internals of a block without updating the tests.

Given the choice of working with a dev who knows how to write a bubble sort[1] and a dev doesn't but does write tests, I'd go for the latter.

[1] To be honest, if someone in my team even considered writing their own sort function, from memory or by googling, I'd have a quiet word. Use a library. Preferably a well-tested one.

But that comes with the way I write my code - modular, i.e. broken into small, readable and reusable units. Well, if I'm doing a something that requires shaving off any redundant CPU cycle, that's another story, but as we know, premature optimization is the root of all evil. You won't see anywhere in my code long functions/methods, endlessly nested IF-THENs, and similar junk - writing simple, unfancy, DRY code drops the need for unit tests to almost zero. Using long, but meaningful identifiers drop the need for inline documentation.

I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there!

There are way too many coders today and very few engineers!

I don't really understand this point. UnitTest and SUnit, that all subsequent unit testing frameworks are based on, were released in about 1990. "Extreme Programming" was a big thing in the mid-90s and that featured test frameworks as a core component. Automated testing isn't new. There are plenty of old books that advocate exactly the "new and trendy" processes you decry. If your argument is "Write code like engineers did 20+ years ago!", then that includes automated testing.

I strongly suspect that we're not actually that far apart in our thinking. I don't believe that unit tests magically make your code better. You can't develop a solution to a problem you don't fully understand by throwing more and more tests at it. Developers still need to take the time to think. I believe a lot of my enthusiasm for testing comes from the belief (...experience...) that there are plenty of developers out there who, as you put it it, are coders rather than engineers. My tests pick up their mistakes (and mine, because sometimes I'm not at my best). Maybe, if you're very fortunate, you've managed to surround yourself with a team who are all really good engineers who genuinely don't need to test things because they're rigorous to the point of infallibility. I haven't, and I work in an industry that means I probably never will, so tests are necessary.

Advocating testing is much, much more productive, and will lead to better software in the long run, than advocating developers write better code.

I didn't mean unit testing is new or useless - just that it's being abused ignoring the benefit-cost ratio and negatively affecting you thought process to rely on something unreliable instead on focusing on code quality - tests are no panacea as code today is more tested than ever, but is also buggier than ever as well.

As a summary: Just think more when you write code, don't get into the vicious circle of try-refresh-repeat, and having tests in place is no excuse for poor code.

Unit testing make you a lot more efficient. You can choose whether to spend that efficiency producing less buggy code in the same time with the same functionality, equally buggy code quicker with the same functionality, or equally buggy code in the same time with more functionality. Most of the time businesses quite reasonably decide the second or third option is more valuable.

This persists, every suggestion to refactor structure rebuffed, and this persists until the code debt is so high, it takes 4-5x as long to add a feature as it should. Where, if you're lucky, you can make a new version using only 3-5 year old technology, instead of the decade old stuff you've been supporting for half a decade. Even then the 2-5yo stuff isn't as nice as it was sold, but it's "enforced" by the company powers that be (god I hate angular sometimes).

We have better procedures and tools. The groups not using version control, unit tests, peer reviews and other common means to increase quality will be out-competed by those who do.

Just write the best software you can, with the best group you can in the mean time and in the long run this will sort itself. Of if you think you can sort it out, try to.

I don't know what "sorted out" looks like but I would not be surprised to see apprenticeships like plumbing and HVAC or certifications like medicine and law. Sorted out could look like just about anything, perhaps we will be drenched in shitty software until unit testing is taught to second graders along-side basic arithmetic.

30 years ago it was definitely an industry. The commercial games market exploded with the arrival of cheap 8-bit micros in the early 80s. Mini and mainframe application development has been around for a lot longer.

Commercial software development has been happening since the 1950s.

https://en.wikipedia.org/wiki/LEO_(computer)

"Sorted out" means that software doesn't fail in stupid, avoidable ways.

The current state of the industry is shockingly bad. But users have been trained to expect broken software, developers rarely have enough of quality ethic to care about those boring bug fixes, and management just wants more money.

So here we are.

Personally I blame Microsoft for gifting the industry with a tradition of bullshit EULAs that more or less said "We can ship any old bug-ridden crap we feel like, and we're not responsible if it blows up in your face and takes your business down. Besides, if something goes wrong it's clearly your fault for being too stupid and ignorant to use the software properly. Whatever - definitely not our fault, so don't even think about suing."

After the Pavlovian conditioning and Stockholm syndrome set in, it became impossible to expect consumer pushback.

How old is a 60 year old industry? It's the time it took to go from the first Write brothers airplane to jet airliners and rockets into orbit. It's less than the time from the discovery of DNA to full sequencing of the human genome. Between 1850 and 1910, steamships went from barely worthwhile to gigantic ocean-going liners (RMS Olympic) and battleships (HMS Dreadnought).

The software industry is not young. The third generation of developers are entering the workforce. Some of them have grandparents who were professional software developers. The industry has completed (or failed at) 100's of thousands (if not millions) of major projects.

IMO, far far too many people working in the industry simply refuse to learn from the past. But that's a rant for another day :-)

Pretty much that. We are still at paleolithic levels, even if progress has been fast.

Only very talented or disciplined people manage to write flawless code without stumbling over their own bugs first. A good, opinionated, statically typed language helps, IMHO (scripting languages are one of the reasons for crappy web pages).

  ERROR IN OR NEAR CARD 1, COLUMN 1. 
  0C7 ABEND.
  ABORT.
  CORE DUMP FOLLOWS:
  ...

[1] http://hallofshame.gp.co.at/stupid.htm

In my experience, it's usually because there was something more important to do.

I don't think it's fair to criticize these decisions unless you know what was done instead.

I think companies should start caring more about their quality and users should stop giving money to those that don't. Some of these silly bugs are pretty ridiculous and should never have happened.

More layers = more bugs, both at the software level and the business level. And there are a lot more layers now. We're not just compiling raw ASM or C and handing it to the end-user anymore. Every couple of years we add more layers to both.

"Hello- new account signups are temporarily unavailable from this network address space used by your Internet Service Provider.'

Flash forward 2 or 3 years. They've gotta have it fixed by now, right?

Nope.

So, kind of doubting its an IP range blacklist thing.

Writing new stuff is like building model airplanes, fun.

Bug fixing is like chores, unless someone gives you some kind of "incentive" to do them you don't.

May favorite tasks are not debugging though, but getting the chance to refactor a mess into something better.

Products aren't perfect. Whether they have frustrating bugs or are missing a useful feature, there's always room for improvement. The best way to help them improve is to give them feedback.

Unfortunately most companies aren't the best at taking feedback. They either don't provide a way to give feedback or don't prioritize it enough in their roadmap.

Which is why we created Product Pains, a new feedback channel for every mobile app and website. It works like so:

- People can post feedback about any product.

- People can also vote and comment on feedback.

- Teams can subscribe to feedback about their products and mark feedback as "In Progress" or "Fixed".

Voting is critical because teams get a clean, prioritized list of the issues that are most important to their users. Rather than having to manually aggregate individual app store reviews, emails, tweets, etc, they do virtually no work.

It's so satisfying to see a Product Rep mark your feedback as "fixed" and know you had an impact on their product and everyone who uses it. I'd love to see your feedback on Product Pains.

Software updates alone will expose you to more versions, so you'll have more chances to see different bugs (rather than the same ones that you learn to adjust to or ignore).

For this reason, the example Shuttle's software misses the mark. Writing code for a single known device is by orders of magnitude a simpler problem than writing code for numerous permutations of hardware.

It's not like that. Sometimes they are expected to function in a presence of any kind of errors, other times - not so much and everyone is ok with them breaking occasionally. But we really do have a way to make software that functions reliably in a presence of errors.

At my last company i was an older developer in a mostly younger team.

We were working on a full rewrite of our product. Version 2 was going to address all the hastily patched together misfeatures of version 1.

Even with this admission that we had a quality problem, I could barely convince them to let me take time to design the new version.

I was supposed to be the architect in charge of designing the new system, and I was constantly being rushed. I would tell them that if we think this through, we'll have a more coherent and stable product.

It was like I was talking Swahili to them.

On the few parts of the system where I was given enough time, I got very few bug reports. As for the rest, well I did what I could. It's no use being a martyr.

Why expect professionalism from people who aren't treated like professionals and shown the respect that would normally be their due?

Every day, I encounter parts of the codebase that could be refactored or sections of a page that probably do not make sense to half of the user base, but in the eyes of management, this is not a problem as customers will learn. If I were to spend all day polishing aspects of the site, that would not be as preferable as working on a major feature release.

It seems many users like myself don't even notice errors any more or have developed an instinct what software or services to stay away from, have low expectations from support (read a logfile?) and a general disdain for a lot of what is going on by using adblocker or avoiding switching services unless really necessary.

So yea, we've given up mostly :)

Yesterday I finally got fed up with my cheap Android phone and flashed it with a modded rom. It took probably 8 hours of reading and downloading and testing and waiting to get it into a working state, because there are so many points along the chain where a little misconfiguration breaks the process, and the people making mods often have working software with poor documentation and inadequate testing.

In the end, there just is never enough time to go around to make it perfect for everyone in every use case. You have to choose carefully when you want to fight the battle - and you can expect to lose, a lot of the time.

But it's probably all due to one simple thing; people aren't encouraged to do things well, they're encouraged to get them done by the 'deadline' at all costs. Which often means writing hacky code, not testing edge cases (or sometimes, any cases), and then hoping anything that breaks can be fixed later.

The latter is also why both web development and game development is arguably more messed up than any other software development, because patches are seen as fairly easy and inevitable. Why get it right the first time when it can be fixed 'post production'?

Write a web UI? Prepare to re-write it next year. Desktop is reasonably stable but now desktop is "dead" and mobile is the new thing. Mobile is a rapidly moving target and there's lots of platform fragmentation. Everyone knows next year or the year after mobile as we know it will now be "dead" and time to rewrite everything all over again. There will be VR and AR which will demand entirely new interface metaphors, totally new platforms, etc.

I didn't even start in on the hip language of the week. Now we have to rewrite it all in Go, or Rust, or Swift, or ...

If everything is changing this fast there's little incentive to perfect anything. It'll be obsolete next year. Just ship ship ship and then throw it away and ship again.

Some of this churn really is related to progress but some of it isn't. I'm skeptical of whether all of it is really necessary.

Have you ever written desktop GUI programs? ;) Particularly on Linux, but I remember that when I was still writing .NET programs on Windows, it was a running gag that every major .NET release brought a completely new UI framework.

From https://tools.ietf.org/rfc/rfc6143.txt:

> To form the key, the password is truncated to eight characters

I think the 8 character limitation is helpful. Because if you need to protect yourself against it, you can ask "but wtf do I really want to do? Probably not a VNC server..."

When I balked he acted all offended and told me they work with some of the biggest companies in the industry, they see lots of stuff on customer's machines, and are totally trustworthy.