Software sucks because too often developers fail to learn what the software is supposed to do.

Developers trivialize things and interpret them in far "superior" ways that lead to huge gaps of "they never told us".

Development has to move from just coding, to learning to first understand what details are being managed, and how those details interact in a system in all the stages the details/data exist.

If we believe every business is becoming a software business, the reverse is true, all software developers must understand the business more and continually develop the skills to be the bridge between business goals and technology.

How to do that?

Shut the hell up and learn.

Ask (and learn) why things are done a certain way. Uncover any competitive advantages the business has from doing things a certain way before getting on the high horse and deciding to improve the world because it's so obvious. Developers may be surrounded by non-techs, but they certainly might be surprised to see the organization itself does have processes and competitive advantages that have to be maintained for the business to survive.

Avoiding the classic SAP-esq kiss of death of doing it the SAP way, wiping out the competitive advantage (seen first hand), and then spending tons of money customizing and automating any ERP to get back to what they had before (and more) seems silly, but I can't say the 70% of failed software projects fare much better.

So, before we think we understand something, shut up.

Before we think we know better, shut up.

Before we think we can simplify things, shut up.

Before we think we can make things more efficient, shut up.

Shut up, listen to the people using the current systems and processes and learn what is working for them, or not, first.

Shut up and learn. Don't finish people's sentences. Don't tune out. Don't think things are beneath you. Don't think you've seen it before, or built it before.

At each step ask them if you understand their process correctly before going off to formulate a faster way of doing things for their confirmation.

Software has the power to uplift the lives of people and help them get more done with less effort. If you don't value this, don't make the rest of us look bad for your laziness and inability to continually develop your own skills.

Once you have learnt why the business does what it does, the way it does, it's fair to ask the question "How should it be?", and see what differs. That, is the beginning of what you should start thinking about.

Having integrated custom systems and built new ones to replace existing ones since '99, this is the single worst thing I see. Enough developers simply don't have a healthy paranoia of their understanding. Knowing a little bit about something can make developers just as dangerous as the "business" folks they judge for doing the same. It all comes out in the wash with the 70% software failure rate.

Without understanding the data of the business, how it interacts, exists in different stages, and how it needs to be input/output, and why, amongst other things is the leading contributor to software failure.

It's as much "the customer didn't know what they wanted" as "developers failed to understand their job is to go learn the business first and then design something to build".

To be clear, this can mean working in people's positions first hand to see what they're going through / facing that they can't explain to you.

It can mean seeing what state a business is in, infancy (no systems or processes), adolescence (some systems or processes), or maturity (a mature system and process, even if it's all manual).

Do those three scenarios equal one approach to all of them? Hell no.

There is, though, a few common things to keep in mind:

- Ask customers to teach you the business as they know it first. Pretend you're the next apprentice, or the owner's right hand man. Ask to be taught not just how to do everything, but why it's done that way.

- Your goal is to get more done with less effort. The software you design and build should not simply make less work for some, and more for others. It should free people from BEING the tools and systems, to USING the tools and systems. The people of an organization should do what they know best, instead of being computers, they should be interacting with each other, and customers.

I could go on a long time about this. But it's Sunday and I hope the positive wishes come through.