Hacker News Reader

> 1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care.

I feel like people exagerrate this idea to prove a point that, ultimately, sales is the gateway to money. Which is fair and important to keep in mind. But, worded like this, it goes too far. Sales and marketing do cost money. They can cost a lot of money, and it's not always as tangible as real product features. Non-marketing people tend to handwave away how hard it can be.

And the product is important. It's much easier to sell a product if it has the features a client is looking for. To do otherwise is a whole different game that will also cost a lot of money but is feasible given certain conditions. For example, building a really strong brand where trustworthiness is more important than price/quality.

Sales is the gateway to money. Parent never said it wasn't important to build a great product, they said that even if you have the most amazing product if it doesn't sell there is no money coming in.

To your point, the goal of "trustworthiness" is to translate into more future sales.

Yes, product quality is important for two reasons:

1. A high quality product reduces the effort on the sales people. It’s nice when a product sales itself on quality alone and it’s also nice when sales can just bank on word of mouth marketing.

2. High quality products cost more to build but less to maintain, scale, extend. That results in predictability that is otherwise absent and expensive.

I think this brings up another good point: code is NOT the whole product, but part of the product. Whether it solves an user pain point, and how easily it can be used (UX) is just as important. If you’re just coding without understanding how it fits in, you’re just a coder, not a software engineer

> Software only costs money.

I assume this ignores hobbyist coders.

What’s the point of even replying to comments like grandparent. Those points are phrased as person-specific dogmas, not advice.

What's the point of replying to any comments? Sometimes people claim to want advice and then cry and whine if its not reaffirming what they already believe. Sometimes people just want to feel smart more than be smart. There was an actual Standard study on this and the difference in output was striking.

> Sometimes people just want to feel smart more than be smart.

Yeah.

> The only purpose of software is automation. There is ultimately no other goal. When your peers start talking about frameworks, easiness, a bunch of tools, or other bullshit realize they have absolutely no idea what they are doing.

This relates back to a course I took about software architecture. There's a guy called Johannes Siedersleben who separates software into three blood groups: A, T and 0.

According to his model, type A contains domain-specific business logic, type T technical code and type 0 is the glue. One should strive to keep these highly cohesive and especially loosely coupled.

I found this an interesting way to think about software and it made me realize that a majority of projects contain mostly type A code while most stuff university teaches is how to write type T code.

I'm struggling to find any information about this, either from Siedersleben or others, at least in English. Can you find any sources you can point me to?

Or, can you explain further? I'm not clear, for example, what you mean by "technical code."

And when you mention "the glue" are you talking mainly about APIs and protocols of all sorts (defined loosely)? This is where the edges of systems coincide and intended side effects reside.

Here's a slide deck from the Technical University of Dresden that goes into it a little in English language: https://st.inf.tu-dresden.de/files/teaching/ss11/swt/Vorlesu...

If you are interested I can look for some older material, just shoot me an e-mail.

Yes, I understood that type 0 does exactly what you describe - Covering the edges of type T and type A systems.

Thank you!

What is the difference between T and O?

Otherwise, yeah, the separation of domain specific code and "infrastructure" code is not novel at all.

If ever you work at a place where the software does not make money or is treated as such then you should consider leaving. You will be treated like a cleaner, i.e. it doesn't matter how well you can clean the office if it has zero impact on revenue, they just want the cheapest.

Everywhere else, your worth is the value you generated multiplied by the number of people it interacts with.

The closer or more direct the path is from the work you do to the value generated, the more you will be valued in that company. This is why Sales can be valued so highly, but if you implement X to win contract Y worth Z where Z is a very big number, your worth is quite clear and it's obvious you should move on if you're treated as a cost in such cases.

> 1. Software does not make money. Not ever. Sales makes money. Software only costs money. When your developer peers get confused, distracted, or lost on this matter you better hope your employer is either too big, too stupid, or too wealthy to care.

I do not like this comparison, mostly because it leads to out weight one for another. We currently have the situation that we are understaffed in dev and overstaffed in sales, but sales does not generate enough revenue to justify their existence. However, we can also not deliver as much features as we like, because the dev department is too small.

The failure to properly administer a business does not make the sales/software cost center rule less true. I have seen this failure repeated exactly as you describe a few times in my career, though. I have also seen some major brands anticipate this problem and over correct for it by hiring too many developers without any kind of discipline or unifying vision.

This is the perspective I’ve come to learn as well. Fact of the matter is what you want to do (and perhaps sell) is what actually matters, not the tools you use to achieve it. Programming language, frameworks, monitoring tech, monolith, microservices etc don’t matter at all as long as you are trading fine, able to deal with failures and move on with checks for next time, able to retain/convert customers and so on. As long as the business is served by the tech within the business constraints, the tech can be abstracted away from the business. Not to say it isn’t important because you are in fact enabling or accelerating the business, but the business is what matters.

The tools only start mattering when the maintenance and usage of the tools becomes a heavy constraint to doing what you actually want to do (big tech). That doesn’t actually happen very easily.

That's just wrong.

1. It's tautological that you can't make money without some form of sales. And it's tautological that if you're employee you cost money. Sure you can sell anything even a rock (see "Pet Rock"), but if the company is making money by selling software, then yes, the software makes money, otherwise your company would have its sales trying to sell rocks.

2. Games aren't for automation. They're for players to have fun. People have also written software as some form of art. You are not in a position to dismiss them as devoid of purpose.

3. There's more to "practice" to become good at software. There are specific tricks, approaches and attitudes to become good at it.

4. "risk management, cost analysis"... What are you talking about? There are people who write great software who don't deal with this crap (because they can offload this to somebody else). Heck even great companies sometimes do this (by offloading risk to investors). You're delusional if you think "risk management, cost analysis" is needed to be excellent "with absolutely everything else". Was Michael Jordan a master at cost analysis? Was Einstein an expert in risk management?

I'm surprised you have the audacity to write with such an absolute and authoritative tone. If anything, being good at software is to recognize edge cases and situations outside of the stereotypical scenario. It seems you've done the opposite and generalized your personal experiences into some kind of absolute truth.

I have heard this all before. Its excuses to qualify low effort and mediocrity.

1. You are either actively generating money directly with your activity or you are contributing to something else that does but you are only doing a single thing at any given moment. Everything else is just pandering to justify your existence.

2. Games can be anything. You don't need a computer to play Sudoku. What separates video games from paper games is automation. Nobody has so far proven this wrong.

3. There are no tricks to practice. You are over coming challenges or spinning your wheels pretending to do so. That is why beginner experts are so common.

4. I guess you have never managed people or products.

> I'm surprised you have the audacity to write with such an absolute and authoritative tone.

I don't know you, but your words indicate I have been doing this work longer than you have been alive.

> What separates video games from paper games is automation. Nobody has so far proven this wrong.

That's because it's not even wrong

There is no excellence in software — only advanced opinion.

There is. You just can’t be excellent at parts that are constantly changing. Avoid those who bumped more than 3 versions in a decade, they aren’t confident in what they want.

Excellence is a trap. It leads to hubris. An excellent programmer can be really annoying, and excellent code is unnecessary.

Instead of excellence, strive for "working code", collaboration, quality, velocity, improvement, shipping the right thing at the right time. Use debt wisely and move forward.

In this episode of How It's Made: Mediocrity.

Excellence is a trap ... Proceeds to describe characteristics of an excellent developer

Right he's talking about a developer who is caught in the trap.

A better way to put it, is a developer about thinks he's excellent. What someone thinks is, the majority of the time, not inline with what he actually is. Especially for developers who think they are excellent. Looking at you Brian Camacho.

I don't know why you're getting so many down votes here. What you say is unpleasant but it's all true.

It is almost certainly the extremely forceful tone I used coupled with the unpleasantness of content. I am just a dumb Army guy, but I have found that if you want to grab people's attention be direct and be forceful. Otherwise unpleasantness is just ignored.

> 1. Software does not make money. Not ever.

Software creates value that you can exchange or rent in exchange for money. All the big software companies know this, their software developers know this, and that's why those developers are well compensated.

This is a myth of tool creation and this line of thinking goes back to the earliest moments of human history. I believed the same thing for most of my career.

Tools unlock valuable opportunities and this becomes more true with superior technology. The opportunity for accessing value is not profit though. Profit only occurs when income exceeds expenses. The means to access income still costs money, such as Customer Acquisition Cost, whether those means are things like better tools or advertising. Superior software may reduce the time per customer transaction, cost per customer transaction, or increase the number of simultaneous transactions but its still those transactions that drive profit. The software is just a contributing artifact. Most of those transactions probably cannot occur without the help of some software, but without the business transactions the software is just an expense not making money.